手っ取り早くオブジェクト指向的な考え方を身に付けるには

Question

今RubyOnRailsなどの勉強をしているのですが、
どうしても生PHP的な手続き型な書き方が抜けない、というかオブジェクト指向的な考え方ができなくて困っています。
一応継承やらカプセル化やらのオブジェクト指向の概念自体は理解しているつもりなのですが、
Web開発でちゃんとクラス設計しろと言われても「え、そもそもどこをクラスにすればいいの？」というレベルです（普通のGUIアプリだったら多少は活かせるのですが・・・）

そこで質問なのですが、手っ取り早くオブジェクト指向的な考え方（特にWeb開発における）を身に付ける方法ってないでしょうか？
書籍でもサイトでも課題でもなんでもいいので教えていただけると幸いです。

Answer 1

そもそもなぜオブジェクト指向を使うのか。
それは人間から見て分かりやすいからです。

WebでOOというと、たとえばMVCモデルになります。

■掲示板におけるMVCの協力体制
V「ユーザから投稿がありました」
C「ではMは、DBへの登録をお願いします」
M「はい、正常に処理できました」
C「ではVは、ユーザに伝えてください」
V「はい、書き込み成功を通知しました」

こうして責務を分散協調したほうが分かりやすいですよね。
まんべんなく処理がプログラム全体に散らばるよりは。

とくにモダンなフレームワークはMVCなので、
行き当たりばったりに書かれたスクラッチと比較すると、
オブジェクト指向の効果が分かりやすいと思います。

ただこの分かりやすさは、設計的な分かりやすさです。
実装視点では、手続き型よりコーディング量が増え複雑になります。

つまり、トップダウンからふかん的に見下ろして、
はじめて整然と都市計画ができていることが分かるのです。
だから設計にまで視点を引き上げることが必要です。

プログラムの学び始めは実装視点しか持っていませんが、
単語単位 → 行単位 → 制御文単位 → 関数単位と
プログラミングが上達するほど視点が高くなってくるはずなので、
それをさらにクラスの単位に引き上げていきます。

自然言語でたとえると、たとえば英語は単語を並べることしかできないけど、
日本語なら段落単位で発想できる、ということがあるようなイメージです。

オブジェクト指向なのだから、思考の粒度をオブジェクトにします。
クラスベースの言語ならクラスで考えます。

それを「どうやって」やるかが聞きたいんだと思いますが、
とにかく思考や言葉の中にクラスという概念を入れてみます。

たとえば、今まで処理をまとめるときに、
無思考・無批判・無意識に関数にしていたのを、
「クラスにできないか」と考えてみます。

それが習慣化すると、どこをクラスにすべきかも自然と分かってきます。

PHPのオブジェクト指向入門 | オブジェクト指向PHP.NET

具体的にやるべき課題も欲しいでしょうから、上記のサイトを紹介します。

ご質問に「生PHP的な手続き型な書き方が抜けない」とあったので、
上記サイトを見つつ、MVCの考え方を身につけてください。

Answer 2

基本的にはオブジェクト指向とは、書き方のスタイルだと私は考えます。
したがって、なれてしまえば自然とオブジェクト指向的なコーディングになります。

「冷蔵庫にキリンを入れる」ってのがあって、オブジェクト指向に慣れるとなるほどねと思える。キリンをどうやって冷蔵庫に入れるかは、冷蔵庫側の話であって、入れる私の関心事ではないという（現実と乖離している）オブジェクト指向的な考え方です。

このような、理想的なクラスライブラリがすでに存在していると仮定して、あるべきクラス・メソッドを実装なしでどんどん書いていきましょう。

当然コンパイルすると、エラーになるので、そのメソッドを実装しましょう。実装したら、理想とずれていると思うので、再設計すればオブジェクト指向らしいプログラムができていると思います。

この時、この処理は再利用するかどうかを考えながらメソッドを作る必要はありません。それを考える前にメソッドを作って下さい。再利用する必要があったらすればいいだけの話です。

同じ引数を取るメソッドは、別のクラスを作った方がいいです。

そうして、ほとんどのクラスを下記くらいに出来るようになると、オブジェクト指向らしいと認めてもらえると思います。（はじめは冗談のように厳しいと感じるかもしれませんが、慣れると優しい方です。）
・メソッド毎の行数が２０行以内
・メソッドの引数５個以内
・メソッドのループやif文での階層が３つ以内
・クラス変数５個以内

あるべきクラスライブラリの形は想像できて、それが実装できないときはデザインパターンを学びましょう。

別に必ずしもオブジェクト指向で無いといけないというわけでないとおもいますので、
手っ取り早く身につける必要もないとおもうのですが・・・

Answer 3

まず、一つ確認させてください。

どうしても生PHP的な手続き型な書き方が抜けない、というかオブジェクト指向的な考え方ができなくて困っています。

とありますが、具体的にどのように 困って いますか？

たとえば、
0. そろそろ自分もオブジェクト指向的なアプローチができるようになりたい（スキルアップしたい）
0. オブジェクト指向の沿って設計＆実装されたプログラムが読めない
0. いま現実に、従来の手続き型の開発手法では対応しにくい案件に直面し、切実に困っている
など。

もし 1. が主な理由なら、オブジェクト指向的な考え方をモノにするのは難しいかもしれません。なぜなら、自分自身が正にその理由で長年悩んでいるので（笑
でも最近、オブジェクト指向を使うこと（本来は手段に過ぎない）自体が目的化してしまうとダメなんだなぁ〜ってつくづく思います。

2. についてですが、当然のこととして、真の意味でオブジェクト指向になっておらず設計も実装も洗練されていないなら、読めなくても当然、というかわざわざ苦労して読む価値はありません。
もしきちんと書かれたプログラムなら「読める」というレベルに到達しているなら、概念は理解できているので問題ないです。
逆に意味が理解できないならば、先ずは基礎的な概念の習得に注力するのが良いと思います。
実際に使うかどうかに関わらず、オブジェクト指向の概念をしっかりと理解している必要はあると思うので。

3. が主な理由なら大変ですね。
でも、いきなりオブジェクト指向にそってスラスラと開発できるようにはならないので、まずは定評のあるフレームワークを導入し、その推奨された開発スタイルに則って開発を進めてみては？

そもそもオブジェクト指向って、従来の手続き型アプローチでは対応困難な事案があって、工夫を重ねて生み出されたものですよね？そして使ってみると、コーディング量はかえって増えたりしますが実際に「楽」だから使い続けられている訳です。なので…

1. 真の目的を見つめ直す
2. 良いお手本を見つけて読み込む
3. オブジェクト指向に適した題材を探して実際に作ってみる
4. 定評のあるフレームワークを導入して推奨された開発スタイルに身を任せてみる
5. 質問サイトで知恵を借りたり、github等で公開してちゃっかり改善に協力してもらう

みたいなアプローチの仕方もあるかと思います。

参考書ということであれば、たとえば以下のようなものをサラッと読んでみるとか。
（まずは近くの図書館で借りてみて、繰り返し読みたいようであれば購入するのもアリ）
オブジェクト指向でなぜつくるのか 第2版
オブジェクト指向でなぜつくるのか―知っておきたいプログラミング、UML、設計の基礎知識
効率的なWebアプリケーションの作り方 ~PHPによるモダン開発入門

もし__体力__があるなら、使いたいと思うフレームワークのドキュメント類（特に開発者向けの）やソースコード（の一部）を、腰を据えて読み込んでみるのも良いと思います。

結論として、決して手っ取り早くはないのですけれども、

• 適した題材を見つける
• 優れた道具を使用する
• 道具自体について研究してみる

というのが、回り道のようで結局は一番の近道なのかなぁ〜？と考えています。

長くなりましたが、もしご参考になれば幸いです。

Answer 4

そもそも、オブジェクト指向のクラスというのは、「型」だということに注意しましょう。「クラスだからnewでインスタンスを」という狭い概念は捨てたほうがいいです。C++では、intやcharと同様に変数のタイプとして扱うこともできます。色々な使いようがあります。単に関数を寄せ集めてstaticにまとめても便利です。「型」が発展して、テンプレートとかネームスペースという概念に発展していますが、根底にある目的は、グループ化による利便性です。
まずは、この「似たものを集めるグループ化」が成立するためには、どういう条件が必要なのか？その根本を意識できるようにならないとクラス設計ができないでしょう。
クラス設計で専門的な規則としての解説はよくあります。しかし、実践で要になっているのは、整理術です。部屋をどう片づけるかと本質的には同じです。ここのセンスが磨かれていないと、知識はあっても何もできないという状態になります。
共通項を見つけ出して整理するという行動の動機として、多数の似たものがそこに散らばっているという光景が前提としてあるでしょう。すべてがてんでバラバラで、共通項がない場合や、要素数が少ない場合は、そこを無理やりクラスにして整理する意味はありませんよね？
実際のプログラミングにあたって、クラス設計以前にクリアしたい課題として、似たような処理を関数化してまとめる、という習慣づけがあります。もし、これすら普段から行えていないのであれば、関数化から入ることをおすすめします。
似たような処理を関数化できたら（恐らくできていると思いますが）、似たような処理でなくとも一塊の意味のある部分を関数に分離することを目指してみてください。その関数は一度しか呼ばれないと思いますが、それで構いません。そうやって、処理の流れ全体を、別々の関数に収納してしまうと、プログラムのメインの部分は、各関数を呼び出していくだけの羅列になるはずです。それが十行以内に収まるようにしてみてください。
それから、各関数も十行以内になるべく収まるように目指します。そこからさらに関数を呼び出すようにして分割してみてください。（特別な理由があれば、絶対十行以内ということにこだわる必要はありません）
すると、ここで多数の関数が出来上がっていることと思います。多くの関数を眺めていると、自然と共通部分が見えてきます。あなたの整理したいという欲求がくすぐられてくるはずです。「これらを集めて別ファイルにまとめるとどんなにスッキリするか」と。
また、名前の付け方もだんだんと煩わしくなってくるはずです。もっと単純で短い関数名で済ませたくなりませんか？名前の干渉に気を使うことに疲れてきませんか？
そして、各関数に渡しては戻ってこさせているパラメータの数が多すぎになっていませんか？渡したけど実際は使っていなかったりしませんか？
似たような性質のオブジェクトに対する操作について、似たような関数をコピペで量産して対処したりしていませんか？
そもそも、関数化を諦めていませんか？

多数の関数がある場合に沸き起こってくる問題について一つ一つをオブジェクト指向で解決する仕方を覚えていってください。関数の上位にクラスがあるということは、関数の超整理術がクラスなんだということです。クラスを使えば関数化が楽になる、ということです。最近は、むしろ関数化のためにクラスがあるんじゃないかと思うくらいです。
まずは、staticな関数の羅列クラスを作ってみてください。次に、似たようなオブジェクトをfor文で一括処理できることを体験してみてください。
利便性が分かれば楽しくなってきます。それが重要だと思いますよ。

Answer 5

オブジェクト指向にはあまりこだわらないほうがいいです
Ruby on Rails を使うのであれば、RoRにおける定石を学ぶことに専念したほうがいいと思います
本を読んだりネットで検索すればRoRのコード例がたくさん見つかりますよね？
RoRの場合はこうするんだ、というのを学ぶのが一番大切です

10年くらい前、JavaでWebアプリを作るのが流行った時代がありました
当時はアプリケーションサーバとWebサーバを分けて作ってました
その時有名なコンサルタントのマーチン・ファウラーという人が
「ValueObjectとTransactionScriptを使ってサーバを実装しろ」と言いました

ValueObjectというのはクラスを使ってますが実態はただの構造体です
TransactionScriptというのはRoRのControllerと似てて、
一つのクラスに処理フローを上から順に書いただけのものです

これってオブジェクト指向でしょうか？
あんま関係ないですよね
手続き型の言語でサーバ実装するのとたいして変わりありません
でも当時はそれがベストプラクティスだったんです
(サーバが二台あって無理やりオブジェクト指向にすると重くなるだけだった)

正しい設計って文脈によって変わるので、オブジェクト指向にはこだわらないほうがいいです
こだわればこだわるほど教条主義的な頭でっかちになっていって、
ボトルネックになるようなコードを書いてしまいます(実体験)

ですから、仮にSmalltalkで開発してる会社に就職して
・開発はもちろんSmalltalkしか使わない
・データは全てオブジェクト指向データベースにいれる

こういう恵まれた環境であれば、
オブジェクト指向そのものについて学ぶのもよいかもしれませんね

追記です：
MVCという言葉にもこだわらないで下さい
人によって、その人の技術的バックグラウンドによって意味の異なる言葉ですから
あくまでも「RailsにおけるMVCはこうなのね」、というのをコードを読み、実装しながら掴むのが大事です

「RailsにおけるMVC」と考えるなら、抽象的な説明にあまり大きな意味はありません
繰り返しになりますが、Railsのコードを読み・実装するのが大事です

Answer 6

オブジェクト指向は考え方は理解できていても、いざ実践してみると思うようにいかないという方は多いと思います。そんな方々に説明しながら行き着いた個人的なレクチャ方法としては下記の２点です。

①ロジックを図で説明できる状態になる。

UMLのようなクラス図になるのが本当は良いのかも知れませんが、
それほど精密な知識でなくとも、クラスを図で表現してみて、その関係性が整理できるような構成になっていればオブジェクト指向になっているのではないかと思います。

で、次に問題となるのが、肝心要のクラスはどうやって抽出するのか？
というものです。

②クラスは仕様書の名詞から探しだす

実はクラス抽出は考える必要はないと思っています。
クラス構成を考える際にそのインプットとなる設計書は存在するものと思います。
そのインプットを元にクラス設計がされるという流れからすると、
その設計書の文章や図にクラスの原型は隠されていると言えるかと思います。

つまり、インプットとなる設計書の名詞部分をマーキングしていって、
それをすべて抜き出し、図として並べて、作りたい処理に関連する名詞どうしを
線でつないでいきます。
それぞれの関係線には処理依頼する方と依頼される方があり、
依頼される側にはクラスのメソッドとして実装を定義していくのです。

この手法が万能ではありませんが、基本的な流れはつかめるのかなと思います。

Answer 7

クラスの判別が難しい、ということでしたので、クラスの見つけ方を紹介します。
Webに限らず、ソフトウェアを作る時に、ソフトウェアに期待する振る舞いってありますよね。

例えばteratailのようなシステムを考えると

• ユーザーが質問を投稿できる
• ユーザーが回答を投稿できる
• ユーザーが回答に投票できる
• 質問を投稿したユーザーがベストアンサーを選択できる

という振る舞いを期待します。
このシステムのことをtoratoilとでも呼びましょうか。

では、toratoilに登場するクラスはどんなものがあがるでしょうか？少し考えてみてください。

有名なクラス識別法に「名詞抽出法」があります。
上記の振る舞いに登場した名詞をそのままクラスとして扱うのです。
toratoilでは

• ユーザー
• 質問
• 回答
• 質問を投稿したユーザー

がクラスとして抽出できます。

ここで出てきた「質問を投稿したユーザー」は「ユーザー」を特殊化したもの、ととらえることができます。大抵のシステムでは、「質問を投稿したユーザー」は「ユーザー」の一種であることに異論はないでしょう。toratoilを実際に開発するときは、現在開いている質問が、そのユーザーが質問したものであるなら、「質問を投稿したユーザー」として扱う、等条件があります。が、システムに登場する概念を考える時は、そういう詳細は脇に置いておきましょう。

さて、「クラス」の話には「責務」という言葉がよく出てきますが、この「責務」とはなんでしょうか？責務とは、「オブジェクトが果たすべき仕事」と言われたりしますが、toratoilの例だと

• ユーザーは質問を投稿できる

というのが責務の1例です。ユーザーは質問を投稿できる振る舞いを担います。これをコードに落とすと、

class User 
  def ask(question)
    nop
  end
  def answer(answer)
    nop
  end
end 

と言うようなインターフェースになると仮定します。

RailsだとこのUserのようなクラスをModelと呼んでいますよね。このUserを利用するコントローラーのコードは下記のようになるでしょう。

class QuestionController
  def post
    # パラメータから質問を作る(自信なし)
    question = Question.new(params[:question])
    user = User.find(params[:user_id])
    user.ask(question)
  end
end

...最近Railsのコード書いていないので、不正確かもしれません。ここで取り上げたいのは user.ask(question) という部分です。英語に近い記法でコードを記述できています。オブジェクト指向を適切に使ってコードを書いていくと、システムの仕様がそのまま英語化されてコードになるのがオブジェクト指向の1つの利点でしょう。

まとめると、

• オブジェクト指向とは、システムに期待する振る舞いを実現する時、概念をコードに落とすための手段の1つ
• 概念がそのままコードに現れるので、人にとって優しいコードになる

過去10年程度オブエジェクト指向とアジャイル開発と親しく付き合い、DDDやらなんやらを学んで来た結果、オブジェクト指向をこんな風に捉えています。

Answer 8

オブジェクト指向をある程度理解しているのであれば、次はデザインパターンを学ぶことをおすすめします。このデザインパターンは先人の研究とオブジェクト指向の神髄が詰まっています。特にWEB開発であれば、ある程度実装方法はパターンとして確立していることが多いです。

Answer 9

オブジェクトは抽象概念ではなく、具体的な「もの」です。「もの」といっても目に見えて触れることができるtangibleな「もの」もあれば、概念的で、直接見たり触れたりできないintangibleな「もの」もあります。

tangibleなオブジェクトとは、例えば人、車、いす、PC、携帯電話などいわゆる「もの」のことです。人という抽象概念ではなく、具体的な姓名を持つ1人ひとりがオブジェクトなのです。車という抽象概念ではなく、あなたが現在所有しているx社製のナンバーxxxxの車がオブジェクトなのです。あるいは今朝あなたが乗ったタクシーという具体的なものがオブジェクトということになります。

一方、intangibleなオブジェクトとは、旅行、会議、授業、注文などの概念的な「もの」のことです。ただし、旅行という抽象概念ではなく、あなたが今年の夏休みにハワイに行ったという具体的な旅行がオブジェクトです。x月x日x時にxx会議室で行う具体的な会議がオブジェクトです。

Answer 10

私も質問者さんと同じ道をたどってきましたので、経験則からお答えします。

まず、一番最適なのはオブジェクト指向で書かれた
ソースコードをたくさん読むことでしょう。

オブジェクト指向の概念が解って、クラスの設計ができないというのは
経験が不足しており実装例を多くしらないからです。

GitHubなどで良質なコードを片っ端から読んでみてください。
(細かく挙動を追う必要はないのでおおまかな設計を理解してください)

書籍でしたらPHPになりますが以下の本がオススメです
・効率的なWebアプリケーションの作り方 -PHPによるモダン開発入門-
・パーフェクトPHP

あとは、読んだソースの中から設計手法を真似て自分で書いているうちに
自然とオブジェクト指向が身についていると思います。

大事なのはオブジェクト指向が解からなくても、逃げずに学び続ける事です。

ご健闘をお祈りします。

Answer 11

1. クラスの定義
2. クラスのインスタンスの生成
3. クラスのメソッドの呼び出し

それ以外の式は絶対に書かない！と、決めてみたらどうでしょうか。

もうひとつ。

設計するとき、手描きで絵を描くといいです。

絵を描くと、いやでもオブジェクト指向になります。

Answer 12

オブジェクト指向は設計技術なので、実装や言語固有の表現からは設計を深く知るためのものとした方がよろしいかと思います。
感覚的なこともご質問に含まれるのだと思いますが、おすすめは成功例の価値を認めることです。デザインパターンに共感できれば考え方が身に付いた証拠になるのではないでしょうか。

それと大事なことなのですが、手続き指向を捨てようとはしないでください。オブジェクト指向であっても、メソッド内は手続き指向です。「オブジェクト指向は設計技術」と申し上げたことともつながるのですが、大局でこそ有効なのがオブジェクト指向です。コードや処理順を考えるような段階は手続き指向なので、結局は両方ともできなければ開発は成り立ちません。

デザインパターンのおすすめ書籍はこちらです。
結城 浩 - 増補改訂版Java言語で学ぶデザインパターン入門

Answer 13

・手続き型からオブジェクト指向型への思考へ切り替えたい

ということでしたら、手間になってしまいますがリファクタリングを繰り返してはどうでしょうか？
私がオブジェクト指向を始めた当初(90年代前半)は大した文献もなく、試行錯誤していたのですが、今は手法も確立しています。

やり方としては以下の通りです。
1.今までどおりで動くものを作る
2.使われている全ての変数に対してアクセスするメソッド(プロパティ)を切り出す
3.変数を中心にメソッドを集めクラス化する

こういう手順を踏むと情報の中心がどこあるか見えるようになります。
(実際にはそれがクラスになります)

自分のロジックから実際のモデルが見えるので、次からはクラスがどういうものか見えてきますよ。

Answer 14

極端に言えば俺のことは俺が一番知ってる！ってのがオブジェクト指向です

オブジェクト指向ってのはオブジェクト中心の考え方ですが
オブジェクトって何にしても自分の状態やそれを変更する方法ってのを自分自身が一番よく知ってる

たとえばメロンだったら糖度とか温度とか種の数とかね
で、メロンオブジェクトは内部で変更してもいい状態を変える手段（メソッド）も知っているわけです。
たとえば糖度の変化メソッドには気温データ、与えられた水分データ、土地の栄養素が引数に必要だとして、それらを使えばメロンの糖度がどれくらい上がるとか下がるとかの方程式もメロン自身が知っているんですね。

メロンさんは俺が自分のことはよう知ってるから、気温データと水分データと土地の栄養素を俺に渡せば糖度設定できるんじゃって感じです
そうすればだれが設定しても糖度ってのは決まりますよね
たとえば気温がエアコンなのが外気温なのか、与えた水分がチューブから出てるのか農家ががんばってあげてるのか、土地の栄養が実はただの栄養を混ぜまくった土地なのか天然の土地なのか関係なくこの辺を埋めれば、よしよしこの材料がそろったなら糖度が設定できるなとメロンは糖度を設定するわけですよ。

そんな感じで自分のことはよくわかってるのがオブジェクト指向です。

じゃぁ仕事で何をすればいいの？って事ですが
一番は今このシステムの役者（オブジェクト）はどれだけいるのか？を考えることです
役者がわかればシステムの中にあるいろんな変数なんかは誰が一番知ってるのか、知っているべきなのかを考えることです。
そうして配置していくとかなり整理できます。（中にはどっちつかずで迷ったり、個人の正義によってこっちだあっちだという議論もありますが。。。）
注意するのは概念も役者なので形あるものだけじゃなくてたとえば天気や役職といった形のないものも役者になります。

一度こんな感じで分けて考えてみるのを試してみてはいかがでしょうか？