こんにちは、リンクアンドモチベーションの木村と申します。
昨年の4月に入社し、現在プロダクトのAPI開発を担当しています。
ほぼ未経験で入社したため、学びの整理が中心となります。
今回は、設計の重要概念である「凝集性」「結合度」についてまとめました。
参考書籍は「良いコード／悪いコードで学ぶ設計入門」です。
結論、高凝集・疎結合な状態を目指そう！という話です。
凝集性と結合度について
凝集性とは
凝集性とは「モジュール内における、データとロジックのまとまり度合い」のことです。
モジュールはクラス、レイヤー、パッケージなど様々な粒度で扱われますが、高凝集な状態が理想的です。
凝集性が低い状態
凝集性が低い状態とは、機能や役割がバラバラに散らばっている状態のことです。この状態だと、変更に非常に弱い構造になってしまいます。例えば、数学的な計算をするメソッドが、データベースへのアクセスやログの記録も行う場合、凝集性が低いと言えます。
低凝集がもたらす具体的な弊害は以下の通りです。
- 重複コード
- 修正漏れ
重複コードの量産によって、修正する箇所に抜け漏れが出る可能性が高まります。 - 可読性の低下
コードの意図や処理の流れを素早く正確に理解することが難しくなります。見る人のエネルギーを消耗させる要因になります。
そのため、持続的にスムーズな開発を行なっていくためには、設計段階やリファクタリング時に適切に機能・役割でデータやロジックをまとめることが大切です。
結合度とは
結合度とは、「モジュール間の依存の度合いを表す指標」です。
ここで言うモジュールは、凝集性の説明で述べたように、様々な粒度を指します。ここでも、疎結合な状態が理想的です。
密結合な状態
密結合な状態とは、結合度が高い状態のことで、変更時に多くの影響範囲を考慮しなければならなくなる状態を指します。可能な限りモジュールを独立させ、依存関係を低めることが重要です。
クラス設計で重要な原則
次に、クラス設計で重要な原則について2つ紹介します。
単一責任の原則
「一つのクラスには一つの責任のみを持たせるべき」という考え方です。
複数の責任を持つことにより、一方の変更が他方にも影響を及ぼし、バグの原因になることがあります。
そのため、クラスがどんな目的で、どんな役割を担っているのかを理解し、それに基づいて設計、実装を行うことが重要です。
DRY原則
「同じことを繰り返さない」という原則です。
しかし、何でもかんでもまとめてしまうと密結合な状態になってしまいます。似たようなビジネスロジックでも、別の概念である場合があり、その場合は責務も別になるため、分離しなければなりません。この点には注意が必要です。
イメージ
実装していない人にもなんとなくわかるように図を作ってみました。
実装対象の構成
ざっくり以下のような形になっていると思います。
今回はクラスとメソッドを対象に考えます。
複数のクラスをうまく分け、目的・役割を明確にすることで「高凝集・疎結合」を実現できます。
疎結合な状態
密結合な状態
低凝集な状態
これは結構わかりやすいです。
まとめ
設計する際は、
- 同じ機能集団をまとめよう（高凝集）
- 機能集団の相互依存を減らそう（疎結合）
という点に注目しましょう。
自分はまだ実装経験が浅いので、まずイメージを作ることができてよかったです。
設計で考慮すべき点はまだまだ多いので、引き続き学習とアウトプットを行っていきたいと思います。