🐥

【CleanArchitecture】 読書メモ4

2023/02/12に公開

solid原則がレンガを組み合わせて壁や部屋を作る方法と伝える原則だとするならば、コンポーネントの原則は部屋を組み合わせて建物を作る方法を伝える原則。

第12章 コンポーネント

コンポーネントとは、デプロイの単位のこと。

第13章 コンポーネントの凝集性

  • 再利用・リリース投下の原則(REP)
  • 閉鎖性共通の原則(CCP)
  • 前再利用の原則(CRP)

再利用・リリース等価の原則(REP)

再利用の単位とリリースの単位は等価になる。
リリース番号がついていなければ、コンポーネントを再利用できない。
開発者はコンポーネントの新しいリリースが出たことを知る必要があるし、そのリリースで何が変わったのかも知る必要がある。
新しいリリースの通知を受け取った開発者が、そのリリースでの変更内容を確認した上で、あえて古い版を使い続けるということもあるので、適切な通知とリリースドキュメントを用意することが欠かせない。
この原則を設計の観点で考えると、コンポーネントを形成するクラスやモジュールは凝集性のあるグループでなければいけない。
また、一つのコンポーネントを形成するクラスやモジュールは、まとめてリリース可能でなければいけない。
REPの弱点は他の二つの原則の強みでも補いきれない。

閉鎖性共通の原則(CCP)

同じ理由、同じタイミングで変更されるクラスをコンポーネントにまとめること。変更の理由やタイミングが異なるクラスは、別のコンポーネントに分けること。
※SRPではコンポーネントではなくクラスで説明してある
CCPは「変更の種類が似ているクラスを一つのコンポーネントにまとめる」と噛み砕いている。

単一責任の原則との類似点

同じタイミング、同じ理由で変更するものはひとまとめにすること。
変更のタイミングや理由が異なるものは別々に分けること。

全再利用の原則(CRP)

コンポーネントのユーザーに対して、実際には使わないものへの依存を強要してはいけない。
一つのクラスだけを再利用することは滅多にない。他のクラスと組み合わせて、再利用可能な抽象として用いることが多い。全再利用の原則(CRP)は、そうしたクラスを同じコンポーネントにまとめるように説いている。
コンポーネントに依存するのであれば、コンポーネントに含まれる全てのクラスに依存するようにしておきたい。言い換えれば、一つのコンポーネントにまとめるクラスはどれも切り離させないものばかりにしておきたい。つまり、依存するクラスもあれば依存しないクラスもあると言った状況は避けておきたい。そのような状態では、本来不要であるはずの再デプロイに手間がかかってしまう。
CRPはどのクラスをひとまとめにすべきかよりも、どのクラスをひとまとめにすべきではないかを伝える原則。密結合してないクラスを同じコンポーネントにまとめるべきではない。

インターフェイス分離の原則との関係

CRPはISPを一般化してる。
ISPは使ってないメソッドを持つクラスに依存しないように伝えている。一歩の全再利用の原則は、使っていないクラスを持つコンポーネントに依存しないように伝えている。
これらはどちらも、以下のようにまとめられる。
不要なものには依存しないこと。

コンポーネントの凝集性のテンション図

再利用・リリース等価の原則(REP)と閉鎖性共通の原則(CCP)は包含関係にある。どちらも、一つのコンポーネントを大きくする方向に動く。
一方全再利用の原則(CRP)はこれらとは相反する原則で、コンポーネントを小さくする方向に動くもの。

Discussion

ログインするとコメントできます