問題: 依存性を弱め、変更による影響を小さくし、再利用性を高めるにはどのようにすればよいか。
結合(coupling)は、1つの要素が他の要素に対し、どの程度の強さで接続するか、把握するか、あるいは依存するかを表す尺度です。結合性が疎な(または弱い)要素は、依存する要素がさほど多くありません。「多い」の程度はコンテキストによって異なりますが、とにかく検証してみましょう。ここでいう要素には、クラス、サブシステム、システムなどが含まれます。結合性が密な(あるいは強い)クラスは、多くのクラスに依存してしまいます。このようなクラスは以下のような問題があるため、望ましくありません。
* 関係するクラスになされた変更によってローカルの変更も強いられる。
* 単独では理解しにくい。
* そのクラスを使用するにはそのクラスが依存するクラスも存在しなければならないため、再利用しにくい。
解決策: 結合性が低くなるように責任を割り当てます。複数の選択肢を評価する場合にもこの原則を用います。
解説: 疎結合性(Low Coupling)パターンは、設計のあらゆる意思決定において考慮する必要のある原則です。常に考慮すべき根本的な目標なのです。疎結合性は、設計者があらゆる意思決定を評価する際に適用する評価用の原則でもあります。
C++、Javaのようなオブジェクト指向言語において、TypeXからTypeYへの結合が発生する一般的な状況には以下のものがあります。
* TypeXが、TypeYのインスタンスあるいはTypeY自体を参照する属性(データメンバまたはインスタンス変数)を持つ。
* TypeXオブジェクトがTypeYオブジェクトのサービス(メソッド)を呼ぶ。
* TypeXが、何らかの手段でTypeYのインスタンスあるいはTypeY自体を参照するメソッドをもつ。
ここでいう手段には、TypeY型のパラメタまたはローカル変数、TypeYのインスタンスであるメッセージから
返されるオブジェクトなどがある。(TypeXがTypeYをメソッドで使う。(引数、ローカル変数))
* TypeXがTypeYの直接的または間接的なサブクラスである。
* TypeYがインターフェイスであり、かつ、TypeXがそのインターフェイスを実装する。
疎結合性パターンを意識し、好ましくない結果をもたらす度合まで結合を強めることのないように責任を割り当ててください。
疎結合性は、変更の影響の少ない、より高い独立性をもつクラスの設計を支援します。
疎結合性パターンを情報エキスパートや高凝集性など他のパターンと切り離しては考察できません。責任割り当ての選択肢に影響する複数の設計原則の1つです。
サブクラスはそのスーパークラスに強く結合されます。スーパークラスからの導出には強い結合が伴うため、その決定には慎重な検討が必要です。
結合が強すぎるかどうかの絶対的な測定基準はありません。重要なことは、現在の結合の度合を判断し、結合の強さが問題を引き起こすかどうかを判定することです。ほとんどの場合は、もともと総称的な性質をもっていて再利用性の可能性が高いクラスは、とくに結合性を低くしておくべきです。
疎結合性の極端なケースはクラス間に結合がまったくない状態ですが、これは望ましくありません。オブジェクトテクノロジの中核は、メッセージを介してコミュニケーションし合う、接続されたオブジェクトでシステムを構成することだからです。疎結合性が過度に適用されると、設計の品質が低下します。単なるデータの記憶場所でしかない、活動的でない結合ゼロのオブジェクトによってすべての仕事をする、凝集性に乏しく、不相応に大きい、複雑なアクティブオブジェクトが生み出されます。接続されたオブジェクト間の協調によってタスクが遂行される
オブジェクト指向システムを構築するには、クラス間にある程度の結合があることが普通であり、これは必要でもあります。
適用できない状況: 安定した要素や広く普及している要素とは、密に結合してもほとんど問題ではありません。たとえば、J2EEアプリケーションはそれ自体を安全にJavaライブラリ(java.utilなど)に結合できますが、これはJavaライブラリが安定し、広く普及しているからです。
注力する箇所の選定: 密な結合自体が問題なのではなく、インターフェースや、実装、あるいは存在自体など、何らかの不安定要因を抱えた要素と密に結合することが問題なのです。
これは重要な点です。設計者としては、柔軟性を加え、詳細と実装をカプセル化し、一般にシステムの多くの部分を疎結合に設計しようとするものですが、現実には必要でない場所で、「将来の保証」のためや結合性を弱くすること自体を目的として労力を費やすのは、時間の浪費です。
物事の疎結合化とカプセル化において注力する箇所を選定しなければなりません。実際に不安定な箇所や進化の速い箇所に集中するのです。
-利点-
* 他のコンポーネントの変化に影響されない。
* 単独で理解しやすい。
* 再利用に便利である。
-背景-
結合性と凝集性は基礎的な設計原則であり、すべてのソフトウェア開発者がこの原則に配慮し、この原則を適用すべきです。
-関係のあるパターン-
* 防護壁パターン
最終更新：2009年06月22日 04:56
