背景

ソフトウェアの凝集度について復習したことを備忘録として残しておく。
結合度とセットになっていることが多いが、結合度については別の記事にすることにする。

目的：モジュール・クラス設計の根拠を説明するときに、
「凝集度レベルがxxxなので、こちらの設計のほうがより良いと考えました」と 当たり前のように 説明できる。

参考文献

1970年代に Larry Constantine と Edward Yourdon によって定義された、
モジュール・クラスが単一の目的だけを有しているかどうかの尺度。
元は化学の世界から来た用語らしい。

以下の1から7の順でコヒージョンのレベルが定義されていて、
上位になるほどコヒージョンが高く、単一の目的を有していることを示す。
通信的コヒージョンのレベルまでが、コヒージョンが高いと言えるレベルです。

コヒージョンのことだけで言うとコヒージョンが高い方が良いのですが、
全部を単一の目的しか持たないようにはできないし、状況に応じて使い分ける必要がありますね。

以下に、各コヒージョンのレベルの定義と、
考えてみた一例（ドラえもん）を載せる。

どこでもドアは移動するという単一の目的しか持っていない。

タイムマシンは、時空というデータを持ち、
目標時代設定、時空警察に連絡、移動という複数の順序動作をひとまとめにしている。

「四次元空間」という中心となるデータに対する入出力が詰まっているクラス。
この使い方が一番多いですかね。

「どら焼き買い出しマシーン」は、中心となるデータは存在しておらず、
どら焼き買い出しの順序的な関連があるので、一つのモジュールになっています。
「スーパーに移動」と、「どらやき購入」の要素に関連がないので、
何をしているのか外側から想像しずらくなり、保守性が落ちます。

「どらやき買い出しマシーン」に、ママから言われた「通帳記帳」の処理を追加したモジュールです。
あとから見ると、何の因果関係もないけど、たまたまママから頼まれたので
一部修正していくと、一時的コヒージョンレベルになります。

改善ポイント：
複数の目的が含まれているので、
通帳記帳と、どら焼き購入、移動を別の道具（モジュール）にする。

「外部からの論理的な理由」というのが、「のび太がやりたいこと」に相当します。
のび太のやりたいことはまとまったミニドラですが、できることは何の関係もないモジュールです。

凝集度が高いメリット：

ソフトウェアの品質（凝集度）について、例を用いて復習しました。
一概に機能的コヒージョンでなければいけない訳ではありませんが、
凝集度の高いモジュール・クラス設計ができるように常に意識していこうと思います。