See the Elephant

1992生まれのプログラマが書くエンジニアブログ

クリーンアーキテクチャ REP, CCP, CRPを学ぶとSOLIDがアーキテクチャに対しても有効なことがわかる。

クリーンアーキテクチャ REP, CCP, CRPを学ぶとSOLIDがアーキテクチャに対しても有効なことがわかる。

クリーンアーキテクチャ第13章を読んでいる。

REP, CCP, CRPについて学んだのでメモ。

SOLIDの教えがそのままアーキテクチャに適用できると知り、記事にまとめる。

SOLIDの内、 SRP, ISPに非常によく似た原則が登場する

原文に近い表現はこちら

TL;DR

凝集性(CCP: 似たものは集め、別のものは離す)について

 - REP: 同じ変更理由のものは同じリリースで変更されるようなコンポーネントの切り方に(変更理由は1つだけ:SRP)
 - CRP: コンポーネントは切り離せない単位に限定する(不要な物に依存しない: ISP)

コンポーネント

以下、コンポーネントはデプロイの単位 だと思って欲しい。

クラスやモジュールをまとめたものである。

REP, CCP, CRP

これらはコンポーネントの分割や責務の切り分けに関する原則である。

凝集性について述べる以外はSOLIDの内、 SRP, ISPに非常によく似た原則である。

凝集性

コンポーネントの凝集性について語られている。

凝集性とは以下のような性質のことである。

似たものは集まり、別のものは離れる

再利用・リリース等価の原則(REP:The Reuse/Release Equivalence Principle)

コンポーネントのリリースに関する規則。

同じ変更理由によって変更されるクラスやモジュールは同じリリースにまとめられるべき。

つまり 変更対象のクラスやモジュールが同じコンポーネント、グループに属しているべき と説く。

閉鎖性共通の原則(CCP:The Common Closure Principle)

つまりは凝集性のこと。

冒頭で説明した凝集性 似たものは集め、別のものは離す を示している。

CCPでは、 同じ変更理由で変更されるクラスやモジュールは同じコンポーネントにあるべき と説く。

コンポーネント版、SOLIDのSRP。

単一責任の原則(SRP: Single Responsibility Principle)クラスの変更理由は1つ(同じアクター<ユーザやプレースホルダー>) であるべき と説く。

全再利用の原則(CRP:The Common Reuse Principle)

ひとつのコンポーネントにまとめるクラスはどれも切り離せないものばかりにする(不要なものに依存しない)。

コンポーネント版、SOLIDのISP

インタフェース分離の原則 (ISP: Interface Segregation Principle)使っていないメソッドを持つクラス(インタフェース)に依存しない(不要な物に依存しない) と説く。

REP, CCP, CRPを学ぶとSOLIDがアーキテクチャに対しても有効なことがわかる

凝集性(CCP: 似たものは集め、別のものは離す)について

 - REP: 同じ変更理由のものは同じリリースで変更されるようなコンポーネントの切り方に(変更理由は1つだけ:SRP)
 - CRP: コンポーネントは切り離せない単位に限定する(不要な物に依存しない: ISP)

凝集性についてSOLIDのSRP(CCP), ISP(CRP)を適用するとコンポーネント分割や責務の切り分けに有効であることがわかった。

SOLIDを理解すると2度美味しい。

以上