オブジェクト指向のこころ
オブジェクト指向についてもう少し理解を深めたいと思い「オブジェクト指向のこころ」という本を読み始めた。
BEAR.Sunday や Symfony、Ruby に触れているうちに、オブジェクト指向の本質的なところを理解していないと感じたことがきっかけ。
- 本を読み始めた時点の自分
- オブジェクト指向の概要は一応知ってる（つもり）
- それっぽいコードは書ける（と自分では思ってる）
- 知りたいこと
- オブジェクト指向の本質
- そもそも自分の知識は合ってるのか？
まだ途中までしか読んでいないのだけどとてもおもしろい。
自分の認識が曖昧だったところを中心にまとめておく。
オブジェクト指向パラダイム
この本の第1章では、オブジェクト指向プログラミングにおける基本中の基本となる部分について説明されている。オブジェクト指向を理解し、活用するための「準備体操」らしい。
この章を読んでも、オブジェクト指向方法論のエキスパートになれるわけではありません。この章の目的は、オブジェクト指向の基本的な概念をすべて紹介しようというのではなく、本書の残り部分、すなわちエキスパートが実践しているオブジェクト指向設計方法論を理解するための準備運動をしようというものなのです。
おもなキーワード
この章で説明されるおもな内容はこんな感じ。
機能分解
何らかの問題に取り組むとき、機能ごとに小さく分解していく方法をとることが多いよねーという話。大きい問題より小さい問題に取り組む方がより簡単なので、この手法はいろいろなところで使われる。
構造化プログラミングの問題点
プログラミングで上記の手法を用いた場合、分解したすべての処理を「正しい組み合わせ」「正しい順序」で実行するメインプログラムが必要になる。
このメインプログラムは複雑になりがちで、処理全体の責任がメインプログラムに重くのしかかってしまう。
また、処理のどこかで仕様変更が生じた場合の影響範囲も広くなる。
オブジェクト？
そもそもオブジェクト指向パラダイムにおける「オブジェクト」とはどんなものを指すのだろうか。手元にある「たのしいRuby」では、オブジェクト指向について以下のように説明されている。
- プログラムの処理の対象を「データ」ではなく「オブジェクト」として考える
- データ構造を段階的に組み合わせて複雑な情報を表現
- データをプログラム上で表現することでいろいろな操作が可能になる
オブジェクトが自分自身に責任を持つということ
オブジェクト自身に対する処理を振る舞いと呼ぶ。
振る舞いに対する責任はそれぞれのオブジェクト自身が持つ。
このためオブジェクトに含まれる仕様が変更されたとき、おもな影響箇所はそのオブジェクトの中に収まる。
カプセル化
責任を持たせた以上、データや状態もオブジェクト自身が管理する。
このことにより、呼び出す側からオブジェクトの型やデータを意識する必要は少なくなる。また、オブジェクト外からオブジェクト内へ干渉できるような権限は基本的に不要となるはず。
つまりカプセル化（隠蔽）によってオブジェクトと外部との結合度は低くなる！
3つの観点
ソフトウェア技術者であるマーティン・ファウラー氏（Martin Fowler）は、ソフトウェア開発プロセスにおける3つの観点として以下を挙げている。
この3つの観点は、上に行くほど抽象度が高くなる。
抽象度が高いってことはあれです、具体的じゃないってことです。抽象度が低いとより具体的なもの（ソースコードやデータ、演算処理）に近くなる。
概念（conceptual）
- 概念を実装するソフトウェアとは切り離されたもの
- 責任
- 「私が何に対して責任があるのか？」
仕様（specification）
- ソフトウェアのインタフェース
- 振る舞い
- 「私はどのように使用されるのか？」
実装（implementation）
- 具体的な処理
- ソースコード、データ、演算処理
- 「私はどのようにして自信の責任を全うするのか？」
実装レベルからの視点
言語の本などでオブジェクト指向について解説される場合、実装レベルで語られることが多い（言語の本でコードによる実装について解説するのは当たり前だ…）
- クラスの定義の仕方やインスタンスの作成方法
- オブジェクトに対する操作方法
概念レベルからの視点
オブジェクトを呼び出す側から見ると、各機能の責任を負っているオブジェクトたちの「実装」は問題ではない。あるオブジェクトが何を表すのか、あるオブジェクトがどのような振る舞いを持つのか、という視点が重要なはず。
