[Clean Architecture] 7장 SRP: 단일 책임 원칙

SRP 단일 책임 원칙은 단 하나의 일만 해야한다는 원칙이 아니다.

→ 하나의 모듈은 오직 하나의 액터에 대해서만 책임져야 한다.

징후1 : 우발적 중복

그림 7.1을 보면, Employee 클래스에 calculatePay(), reportHours(), save() 이 세 개의 메서드가 있다.

• calculatePay() → CFO
• reportHours() → COO
• save() → CTO

이 클래스의 메서드 들은 3개의 액터에 영향을 미치므로 SRP를 위배한다.

따라서, 서로 다른 액터가 의존하는 코드를 서로 분리해야한다.

징후2: 병합

다른 액터가 각각 SRP가 위반된 클래스의 메서드를 바꾼다면, 서로 충돌나서 병합이 발생할 것이다.

이 병합은 모든 경우를 병합할 수 없기 때문에, 항상 위험이 뒤 따르게 되어있다.

병합책

해결책은 데이터와 메서들르 분리하는 방식이다.

그림 7.3과 같이 메서드가 없는 간단한 데이터 구조인 EmployeeData 클래스를 만들어, 세 개의 클래스가 공유하도록 한다.

이렇게 바꾼다면, 세 클래스는 서로의 존재를 모르게 될 것이다.

이때, 단점도 발생하는데, 개발자가 세 가지 클래스를 인스턴스화 하고 추적해야한다는게 단점이다.

이럴때, Facade 패턴을 쓴다.

• Facade 패턴

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

따라서 개발자는 Facade 패턴을 써서, Employee 클래스에 중요한 메서드는 유지한 채, 덜 중요한 메서드 들에대한 퍼사드를 써서, 해결하면 된다.

결론

단일 책임원칙은 메서드와 클래스 수준의 원칙이다.

상위 수준에서는, 예를들어 컴포넌트 수준에서는 공통 폐쇄 원칙이 된다.