[Clean Architecture]7章SRP:単一責任原則

SRP単一責任原則は一つのことだけをする原則ではありません.
→1つのモジュールは1つのアクチュエータにしか責任を負いません.

兆候1：偶発的な繰り返し

図7.1に示すように、Employeeクラスには、calculatePay()、reportHours()、save()の3つの方法がある.

calculatePay() → CFO

reportHours() → COO

save() → CTO

このような方法は3つのアクチュエータに影響を与えるため,SRPに反する.
したがって,異なるアクチュエータに依存するコードを互いに分離する必要がある.

兆候2:マージ

別のactitorがSRP違反クラスのメソッドをそれぞれ変更すると、競合が発生し、マージが発生します.
この合併は常にリスクを伴う.すべての状況が合併できないからだ.

連結ポリシー

解決策は、データをメザードラーから分離することです.
図7.3に示すように、3つのクラスが共有されるように、メソッドのない単純なデータ構造EmployeeDataクラスが作成される.
このように変えると、3つのクラスはお互いの存在を知らない.

この場合,開発者が3つのクラスをインスタンス化し追跡する必要があるという欠点も現れる.
このときFacadeモードで

Facadeモード

Facade는 "건물의 정면"을 의미하는 단어로 어떤 소프트웨어의 다른 커다란 코드 부분에 대하여 
간략화된 인터페이스를 제공해주는 디자인 패턴을 의미한다.
퍼사드 객체는 복잡한 소프트웨어 바깥쪽의 코드가 라이브러리의 안쪽 코드에 의존하는 일을 감소시켜 주고, 
복잡한 소프트웨어를 사용 할 수 있게 간단한 인터페이스를 제공해준다.
    
[09 퍼사드 패턴 (Facade Pattern)](https://lktprogrammer.tistory.com/42)
    
위의 설명에 의하면, 시청자는 세부 메서드를 알 필요없이 Facade에 의해 바로 시청을 할 수 있게 된다.

したがって,開発者はFacadeモードを用いて,Employeeクラスに対する重要な手法を維持するとともに,あまり重要でない手法に対してpersadを用いて解決することができる.

n/a.結論

単一責任の原則は方法と等級の原則である.
これは、より高いレベル、例えば、素子レベルでは、一般的な閉鎖原則である.