왜?
- SOLID 원칙 중에 하나
- 면접에서 설계도를 리뷰하며, 단일 책임 원칙에 따라 기존 코드가 어떻게 변경되어야하는지 정확히 대답하지 못했다.
- 따라서 예시를 통해 재학습하기로 결정했다.
참고
단일 책임 원칙이란?
- 하나의 클래스로 너무 많은 일을 하지 말고 딱 한 가지 책임만 수행하라는 뜻이다
- 변경 사항이 일어났을 경우, 단일책임원칙을 지켰다면, 하나 클래스 내용만 변경될 것이다.
잘못된 예시
회계팀, 인사팀, 기술팀이 사용하는 메서드는 모두
calulateExtraHour()
에 의존적이다.만약 인사팀에서 해당 로직을 변경되어야 할경우 의도치 않은 나머지 2개의 팀을 모두 검증해야할 필요가 생긴다.
이유는 Employee 클래스에서 회계팀, 인사팀, 기술팀 이렇게 3개의 액터에 대한 책임을 한꺼번에 갖고있기 때문이다.
1
2액터는 시스템을 수행하는 역할을 하는 요소로써, 시스템을 이용하는 사용자, 하드웨어 혹은 외부 시스템이 될 수 있다.
회계팀, 인사팀, 기술팀에서 데이터를 얻기위해 하나의 Employee 클래스를 사용하기 때문에, 3개의 액터가 하나의 클래스를 변경할 수 있는 요인이 되어 SRP 원칙을 어긴 구조라고 하는 것이다.
1 |
|
단일 책임 원칙 적용 코드
- 각자의 caculaterExtraHour() 메서드를 갖고, 외부액터에서 이용시 퍼사드 패턴 적용된 객체만 바라보면된다.
- 해당 구조로 작성된다면, 만약 인사팀에서 해당 로직을 변경되어야 할경우
HourReport.reportHours()
만 변경하면된다. 영향도없음
구조도
EmployeeFacade
1 |
|
EmploySaver, HourReport, PayCalculator
- EmploySaver
1 | public class EmploySaver { |
- HourReport
1 | public class HourReport { |
- PayCaculator
1 | public class PayCalculator { |
SRP 원칙 적용 주의점
클래스명은 책임의 소재를 알수있게 작명
- 어떠한 기능을 담당하는지 명료하게
책임을 분리할때 항상 응집도는 높게, 결합도는 낮은 방향으로 설계
- 응집도는 한 프로그램 요소가 얼마나 뭉쳐있는가에 대한 척도
- 결합도는 프로그램 구성 요소들 간의 의존성을 나타냄
산탄총 수술
- 하나의 책임 담당이 여러 개의 클래스들로 분산되어있는경우, SRP에 입각해 설계변경해야한다
- 여러개의 모듈에서 자체적으로 로깅, 보안, 트랜잭션을 처리하고 있는데, 아무리 로깅과 같은 사소하고 부가적인 기능이라도 여러 모듈에 공통적으로 자주 이용된다면 책임 소지를 분리해 따로 클래스로 관리하라는 뜻이다.