단일 책임 원칙은 하나의 일만 해야한다는 원칙이 아니다.
- 하나의 모듈은 하나의 액터에 대해서만 책임져야 한다.
* 액터 : 변경을 요청하는 사람
📕 징후 1: 우발적 중복
위 Employee 클래스는 세 가지 메서드 calulatePay(), reportHours(), save()를 가진다.
이 세 가지 메서드가 서로 다른 액터에 영향을 주기 때문에 SRP를 위반한다.
따라서, 서로 다른 액터가 의존하는 코드를 서로 분리해야 한다.
📗 징후 2: 병합
하나의 소스 파일에 다양하고 많은 메서드를 포함하면 병합이 자주 발생한다.
이를 해결하기 위해서는 서로 다른 액터를 뒷받침 하는 코드를 서로 분리해야 한다.
📙 해결책
해결책은 데이터와 메소드를 분리하는 방식이다.
메서드가 없는 클래스를 만들어 세개의 클래스를 공유하여 세 클래스가 서로의 존재를 모르게 한다.
이로인해 우연한 중복을 피할 수 있다.
그러나, 이는 클래스를 인스턴스화하고 추적해야한다는 단점이 있다.
이를 해결하기 위해 퍼사드(Facade) 패턴을 활용한다.
따라서 퍼사드 패턴을 활용하여 Employee 클래스에 중요한 메서드를 유지하고, Employee 클래스를 덜 중요한 나머지 메서드들에 대한 퍼사드로 사용하여 문제를 해결한다.
* 퍼사드 패턴 : "건물의 정면"을 의미하는 단어로, 사용자가 어떤 행위를 위해 사용하는 서브 클래스들 사이의 간단한 통합 인터페이스를 제공해주는 역할 / Facde 객체에서 제공하는 메서드를 호출하여 서브 클래스의 사용을 이끌어냄
📘 결론
SRP 는 메서드와 클래스 수준의 원칙이다.
상위 수준에서 다른 형태로도 존재한다.
- 컴포넌트 수준 → 공통 폐쇄 원칙(Common Closure Principle)이 된다.
- 아키텍처 수준 → 아키텍처 경계(Architectural Boundary)의 생성을 책임지는 변경의 축이 된다.
📚 Reference
- Clean Architecture : 소프트웨어 구조와 설계의 원칙
- 퍼사드 패턴 : https://lktprogrammer.tistory.com/42
로그를 생활화