SRP : 단일 책임 원칙

---

SRP는 보통 모든 모듈이 단 하나의 일만 해야한다는 의미로 받아들이기 쉬우나 실 의미는 다음과 같다

단일 모듈은 변경의 이유가 하나, 오직 아나뿐이어야 한다.

변경의 이유를 좀 더 바꿔말하면 다음과 같이 말할 수도 있다.

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

우발적 중복

---

급여 애플리케이션에 Employee 클래스가 있다고 가정하자.

이는 SRP를 위반하고 있는데 한 클래스에서 서로 다른 변경점을 책임지고 있기 때문이다.

• calculatePay() : 회계팀에서 기능을 정의하며, CFO 보고를 위해 사용
• reportHours() : 인사팀에서 기능을 정의하며, COO 보고를 위해 사용
• save() : DBA에서 기능을 정의하며, CTO 보고를 위해 사용

calculatePay()와 reportHours() 가 초과 근무를 제외한 업무 시간을 계산하는 알고리즘을 공유한다고 가정한다.
코드 중복을 피하기 위해 이 알고리즘은 regularHours()로 구현해 공유한다.

현재 상황에서 만약 COO팀에서 초과 근무를 제외한 업무 시간 계산 알고리즘을 수정해야한다 했을 때, regularHours()를 변경하게 된다면 CTO팀, CFO팀에서의 시스템에 문제가 생길 수 밖에 없다.

해결책

---

SRP 원칙을 지키는 해결책은 다양하게 있지만 그 중, 모두가 메서드를 각기 다른 클래스로 분리하는 방식이 있다. 즉, 아무런 메서드가 없는 간단한 데이터 구조 EmployeeDate 클래스를 만들어, 공유하도록 한다.

이 해결책은 세 가지 클래스를 인스턴스화하고 추척해야한다는 단점이 있다. 퍼사드 패턴을 적용하면 이를 해결할 수 있다.

결론

---

단일 책임 원칙은 메서드와 클래스 수준의 원칙이다. 이보다 상위의 두 수준에서는 다른 형태로 다시 등장하는데 컴포넌트 수준에서는 공통 폐쇄 원칙으로, 아키텍처 수준에서는 아키텍처 경계의 생성을 책임지는 변경의 축이 된다.

참조

---

• 클린 아키텍처(소프트웨어 구조와 설계의 원칙) - 로버트 C. 마틴
• [클린아키텍처] 3부. 설계 원칙 SRP