第2部 従来のオブジェクト指向設計における限界
第3章 柔軟なコードを必要とする問題
- クライアントと、クライアントから呼び出される複数のバージョンのサブシステムがあるものとする。
- これらバージョンの異なる複数のサブシステムは、クライアントから呼び出される機能はそれぞれで用意されており、本質的には同じ情報を保持しているにもかかわらず、実装もインタフェースもそれぞれ全く別ものになってしまっている。
- クライアントからあるサブシステムを呼び出す際、バージョンの異なる複数のサブシステムを、同じインタフェースで(クライアントから見て一貫した方法で、違いを意識させずに)呼び出せるようにする必要がある。
- そうすることで、サブシステム側の変更からクライアント側のプログラムを保護することが出来るからである。
- これら複数のサブシステムに仕様変更があったり、さらに新たな別バージョンのサブシステムを追加する対応などが発生するため、柔軟に行えることが求められる。
- つまり、各サブシステムを独立させ、他の部分に発生する変更から影響を受けさせないようにすることがソフトウェアアーキテクチャとして要求される。
第4章 標準的なオブジェクト指向による解決策
- 3章のようなシステムの持つ問題点を標準的なオブジェクト指向によって解決を試みる。
- 各サブシステムに実装された機能ごとの抽象クラスを定義する。
- この抽象クラスから派生させた、各サブシステムごとの機能の具象クラスを定義する。
- これらサブシステムごとの機能の具象クラスから、それぞれのサブシステムの機能を呼び出すようにする。
- この設計には色々と問題があるが、中でも致命的なのは高い結合度である。
- この設計だと、新しいサブシステムが追加されるたびに、サブシステムの機能数だけのクラスが新しく増えてしまうことになる。逆に機能が増えればサブシステムの数だけのクラスが増える。
- このような方法は、システムの改訂に柔軟に対応するという重要な要求には答えられていない。これが標準的なオブジェクト指向設計の限界である。
- このような標準的なオブジェクト指向の設計をしてみた時、論理的には説明できず、ではどうすればいいのかという解決策も当然出てこなかったが、「直感的に」この設計はまずい、ということを感じ取った。
- 第6感は、設計品質を評価する上ではパワフルな指標となる。開発者ならば心の中の声に耳を傾けることの重要性を知るべきである。
- 何か気に入らないものを目にした時、胸騒ぎを感じることがある。これが科学的でない判断なのは百も承知の上だが、直感的に見て設計が気に入らなかったものの、もう一捻りすれば優れた解決策が見つかったという経験は誰しもあるはずである。
