問題: オブジェクトの焦点を明確にし、わかりやすく、管理しやすく、さらには副次効果として疎結合性も促進するにはどのようにすればよいか。
オブジェクト設計では、凝集性(cohesion)(あるいはより具体的に、機能の凝集性)は、要素の責任がどの程度強く関係し、集束されているかを示す尺度です。関係性の高い責任をもち、あまり多くの作業をしない要素の凝集性は高く保たれます。ここでいう要素には、クラス、サブシステムなどが含まれます。
解決策: 凝集性が高くなるように責任を割り当てます。複数の選択肢を評価する場合にもこの原則を用います。
凝集性の低いクラスは、関係性のない仕事をこなしたり、仕事が多すぎたりします。このようなクラスが望ましくないのは、以下のような問題が発生するからです。
* 理解しにくい
* 再利用しにくい
* 保守しにくい
* 脆弱で、変更による影響を絶えず受ける
凝集性の低いクラスは、抽象性の粒度が粗くなったり、本来は他のオブジェクトに委ねるべき責任を負っていることがよくあります。
解説: 高凝集性(High Cohesion)パターンは、疎結合性パターンと同じく、設計のあらゆる意思決定において考慮する必要のある原則です。常に考慮すべき根本的な目標なのです。高凝集性は、設計者が意思決定を評価する際に適用する評価用の原則です。
Graby Boochは、高い機能凝集性を、あるコンポーネント(クラスなど)の要素が「協力し合って、適切な境界のある何らかの振る舞いを行う」際に存在すると説明しています。
機能凝集性の度合を段階に分けて見てみましょう。
- 非常に低い凝集性 - 機能が大きく異なる複数の分野での多くの作業の責任を1つのクラスが単独で負う。
- 低い凝集性 - 1つの機能分野での複雑なタスクの責任を1つのクラスが単独で負う。
- 高い凝集性 - クラスが1つの機能分野で適度の責任を持ち、タスクを遂行するために他のクラスと協調する。
- 中程度の凝集性 - 論理的にクラスの概念に関係するが、相互には関係していない少数の異なる分野において、クラスがライトウェイトで独占的な責任を負う。
(例)【中程度の凝集性】(a)従業員を把握する責任と、(b)各人の経理的情報を把握する責任を完全に負う、Company(企業)という名前のクラスがあると想定します。この場合の2つの分野は企業という概念に論理的に関係していますが、相互に強い結び付きはありません。また、パブリックメソッドの総数が少なく、したがってコードの量も少なめです。
経験上、高凝集性をもつクラスは、機能の関連性の強い、かなり少ない個数のメソッドを持ち、仕事の量があまり多くありません。このようなクラスは、タスクが大きい場合には他のオブジェクトと協調して作業を分担します。
高凝集性をもつクラスの利点は、理解しやすく、保守や再利用も容易なことです。関連性の強い機能が少数の操作にまとめられているため、保守や拡張を簡単に行うことができます。高度に関連付けられた機能の粒度が細かいことも、再利用の可能性を促進します。
その他の古典的な原則: モジュール設計
結合性と凝集性は古くから知られてきたソフトウェア設計の原則です。オブジェクトを用いる設計だからといって、長年にわたって定着している基盤を無視するわけではありません。他にも、結合性と凝集性に強く結びついた原則があります。それはモジュール設計(modular design)を推進することです。次の引用を参考にしてください。
* モジュール性は、高凝集性と疎結合性を備えたモジュール群に分解されたシステムの持つ特性である。(Booch)
高凝集性を備えたメソッドとクラスを生成することによって、モジュール設計が促進されます。基本のオブジェクトレベルでは、モジュール性は個々のメソッドを明確な単一の目的をもつように設計し、関係のある関心ごとのまとまりをクラスにグループ化することによって達成されます。
凝集性と結合性の陰陽: 劣悪な凝集性(低い凝集性)は劣悪な結合性(密な結合性)につながり、逆も同様です。
利点
*設計の明確さと理解しやすさが高まる
*保守と拡張が容易である
*疎結合性も同時に促進されることが多い
*関係性の強い、適度に細分化された機能の再利用性が促進される。凝集性の高いクラスは限定された目的に使用できるからである。
最終更新：2009年06月24日 05:54
