This is version 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 . It is not the current version, and thus it cannot be edited.
[Back to current version]   [Restore this version]

私は単なるエンジニアであって学者や研究者ではないため、ここに書いてある内容は科学的に吟味されたものではありません。
しかし、普段の仕事の中で気付いた合理性のある内容だと思っています。

オブジェクト指向って?#

オブジェクト指向の最初の説明として良く出てくるのが、

• 隠蔽
• 継承
• 多態性

というものです。 これらはオブジェクト指向の特徴を確かに言い表していますが、オブジェクト指向的な設計や実装を初学者が理解するための役に立たないとytpは考えています。少なくとも初心者にとっては百害有って一理無しです。
これから説明するオブジェクト指向に関する原則は、実際の開発現場で皆さんが実践することを目的に書いています。いわば、「開発現場で役立つオブジェクト指向の本質」を解き明かすために書きました。

オブジェクト指向設計に関してはデザインパターンという形で様々な本が書かれていますが、パターンは有用ではあるものの全部を一々覚えてはいられません。そもそもパターンというのは、オブジェクト指向の本質を理解した人が設計した有用な常套手段に名前を付けたものです。囲碁で言う定石です。
しかし定石には必ず理由があり、それらの根底には共通する原則があります。このサイトでは、オブジェクト指向設計における原則を記述しています。つまり、定石を産み出すための原理です。囲碁で言えば手筋(てすじ)が近いでしょうか。
これを理解してしまえばパターンに頼ることなく正しい設計にたどり着けると私は考えています。パターンを否定しているのではありません。パターンの奥に隠れた本質を理解することが大切なのです。

クラス図の読み方#

このサイトでは、UML(Unified Modeling Language)のクラス図(Class Diagrams)がたくさん出て来ます。ご存じない人のためにその読み方を簡単に説明します。次の4つがあります(UMLの定義ではこれ以外もあります)。

1. 集約
2. コンポジット集約
3. 実現
4. 継承

集約#

「AクラスがBクラスを部分として持っている」という関係を表します。「has a の関係」と言われます。「バイク本体とタイヤ」のような関係です。あるタイヤは色々なバイクに取り付けることが可能です。つまりバイク本体とタイヤは独立して存在できます。このような関係です。

コンポジット集約#

「AクラスがBクラスを部分として持っている」という関係は上の集約と同じですが、BクラスのライフサイクルはAクラスと同じであることが異なります。Aクラスが無いとBクラスは存在し得ないのです。例えば「木と木の葉」、または「伝票と伝票明細」のような関係です。単に「コンポジション」とも呼ばれます。

実現#

「Mインタフェースの振る舞いをCクラスが具体化(実装)している」という関係を表します。インタフェースでは、振る舞いの型(パラメータと戻り値)だけを定義し、その具体化(実装)はCクラス側に任せます。インタフェースは「役割」と理解すればいいでしょう。

汎化#

「EとFの性質の共通部分を抜き出してDとした」関係のことです。例えば「ワゴン車とセダンを自動車と呼ぶ」という関係です。俗に「継承」とも呼ばれ、「is a の関係」と言われます( E is a D.)。

このサイトを読む上での注意点#

このサイトに書いてある内容には、皆さんのこれまでの常識をくつがえすものが多々あります。今までの常識にとらわれずに読んで下さい。可能ならば頭を白紙の状態にして、書いてある内容を純粋に吟味してみて下さい。皆さんの開発にきっと役立つはずです。

それでは次ページから、「本には書いてないオブジェクト指向」の始まりです。

本には書いてないオブジェクト指向のページ一覧#

クラスとはデータ構造
責務はクラスではない
クラスにするもの
小物クラス
リンゴ一個とリンゴ一山は異なるクラス
関数とユーティリティクラスは禁止
privateメソッド禁止
どのメソッドをどのクラスで実装すべきか