背景
ソフトウェアの凝集度について復習したことを備忘録として残しておく。
結合度とセットになっていることが多いが、結合度については別の記事にすることにする。
目的：モジュール・クラス設計の根拠を説明するときに、
「凝集度レベルがxxxなので、こちらの設計のほうがより良いと考えました」と 当たり前のように 説明できる。
参考文献
凝集度（コヒージョン）
1970年代に Larry Constantine と Edward Yourdon によって定義された、
モジュール・クラスが単一の目的だけを有しているかどうかの尺度。
元は化学の世界から来た用語らしい。
以下の1から7の順でコヒージョンのレベルが定義されていて、
上位になるほどコヒージョンが高く、単一の目的を有していることを示す。
通信的コヒージョンのレベルまでが、コヒージョンが高いと言えるレベルです。
コヒージョンのことだけで言うとコヒージョンが高い方が良いのですが、
全部を単一の目的しか持たないようにはできないし、状況に応じて使い分ける必要がありますね。
- 機能的
- 逐次的
- 通信的 ※ここまではコヒージョンが高い
- 手順的
- 一時的
- 論理的
- 偶発的
以下に、各コヒージョンのレベルの定義と、
考えてみた一例（ドラえもん）を載せる。
機能的コヒージョン
- 単一の目的しか持たない
どこでもドアは移動するという単一の目的しか持っていない。
逐次的コヒージョン
- 中心となるデータが存在していて、そのデータに対する複数の処理ステップを実行する
タイムマシンは、時空というデータを持ち、
目標時代設定、時空警察に連絡、移動という複数の順序動作をひとまとめにしている。
通信的コヒージョン
- 中心となるデータが存在していて、それに対する入出力処理がランダムに詰まっている
「四次元空間」という中心となるデータに対する入出力が詰まっているクラス。
この使い方が一番多いですかね。
手順的コヒージョン
- 中心となるデータが存在しておらず、順序的な関連性から1つのモジュールになっている
「どら焼き買い出しマシーン」は、中心となるデータは存在しておらず、
どら焼き買い出しの順序的な関連があるので、一つのモジュールになっています。
「スーパーに移動」と、「どらやき購入」の要素に関連がないので、
何をしているのか外側から想像しずらくなり、保守性が落ちます。
一時的コヒージョン
- ある時点において、偶然同時に行ったことをひとまとめにしたモジュール
「どらやき買い出しマシーン」に、ママから言われた「通帳記帳」の処理を追加したモジュールです。
あとから見ると、何の因果関係もないけど、たまたまママから頼まれたので
一部修正していくと、一時的コヒージョンレベルになります。
改善ポイント：
複数の目的が含まれているので、
通帳記帳と、どら焼き購入、移動を別の道具（モジュール）にする。
論理的コヒージョン
- 外部からの論理的な理由で、同類の処理がひとまとめにされたモジュール
「外部からの論理的な理由」というのが、「のび太がやりたいこと」に相当します。
のび太のやりたいことはまとまったミニドラですが、できることは何の関係もないモジュールです。
偶発的コヒージョン
- お互いに何の関係も持たない処理がひとまとめにされているモジュール
まとめ
凝集度が高いメリット：
- 設計の明確さと理解しやすさが高まる
- 保守と拡張が容易である
- 疎結合性も同時に促進されることが多い
- 関連性の強い機能が適度に細分化されることで再利用の可能性が高まる。凝集性の高いクラスは限定された目的に仕様できるからである
ソフトウェアの品質（凝集度）について、例を用いて復習しました。
一概に機能的コヒージョンでなければいけない訳ではありませんが、
凝集度の高いモジュール・クラス設計ができるように常に意識していこうと思います。