これまでコードの分割の仕方と、分割したコードの組み合わせ方を見てきた。今回はグループ化について見てみよう。
クラス同士を組み合わせたらそのまま単一のパッケージとしてリリースしてよいのだろうか?
1つのパッケージでリリースした場合、どこかで不具合修正や機能追加があったとき、また全てリリースしなくてはならない。リリース作業というのは意外と面倒なものだ。またそのように大きな単一パッケージは再利用することが難しい。
分割されたコードをパッケージやライブラリに適切にグループ分けしてリリースすれば運用フェーズにおけるリリース負荷を削減し再利用性を向上することができる。
ではどのようにグループ化すればよいのか?その指針となるのが凝集度だ。
凝集度
- コンポーネントの構成要素が同じ1つの目的を持っていること
- 言い方を変えると余計な目的を持っている構成要素がいないこと
原則
高い凝集度を持ったコンポーネントを作るための原則を以下に示す。これらの原則は相反するところがあるため案件に応じてバランスを取ることが求められる。
再利用・リリース等価の原則
- The Reuse/Release Equivalence Principle
- 再利用する単位とリリースする単位は同じになること
- Pythonの場合はライブラリ単位でリリースするがライブラリ内の全てのクラスを再利用するかしないかのどちらかということ
- 言い換えると再利用できる単位にまとめてリリースすること
- 不要なリリースが減る
閉鎖性共通の原則
- The Common Closure Principle
- 同じ理由で同じタイミングで変更されるものをまとめること
- 保守性が向上する
全再利用の原則
- The Common Reuse Principle
- 再利用できる単位でまとめること
- 再利用性が向上する
分類
凝集度にも程度の分類がある。凝集度の低いもの(Worst)から高いもの(Best)を以下に示す。
なお説明が長くなってしまったので強引に短くするとこんな感じだろうか。
無作為 < 類似した複数機能 < 同じタイミング < 同じ手続き < 同じデータ/順序性 < バケツリレー < 単一タスク
- 偶発的凝集(Coincidental Cohesion)
- 論理的凝集(Logical Cohesion)
- 時間的凝集(Temporal Cohesion)
- 手続き的凝集(Procedural Cohesion)
- 通信的凝集(Communicational Cohesion)
- 逐次的凝集(Sequential Cohesion)
- 機能的凝集(Functional Cohesion)