7장부터 11장은 설계 원칙을 다룬다. SOLID 말이다. 이 원칙은 중간 수준의 소프트웨어 구조가 변경에 유연하고, 이해하기 쉽고, 많은 소프트웨어 시스템에 사용할 수 있는 컴포넌트의 기반이 된다. 중간수준이라는 것은 이 원칙을 모듈 수준에서 작업할 때 적용할 수 있다는 뜻이다. 코드 수준보다 조금 상위의 모듈과 컴포넌트 내부에서 사용되는 소프트웨어 구조를 정의하는데 도움을 준다.
SRP 원칙은 모듈이 단 하나의 일만 해야 한다는 의미가 아니다. 이런 원칙은 더 낮은 수준 즉, 코드 수준에서 사용된다.
SRP 원칙
SRP 원칙의 정의
단일 모듈은 변경의 이유가 하나, 오직 하나뿐이어야 한다.
소프트웨어 시스템은 사용자와 이해관계자를 만족시키기 위해 변경된다. 변경의 이유는 곧 시용자와 이해관계자를 가리킨다. 따라서 SRP는 다음과 같이 바꿔 말할 수 있다.
하나의 모듈은 하나의, 오직 하나의 사용자 또는 이해관계자에 대해서만 책임져야 한다.
시스템이 같은 방식으로 변경되기 원하는 사람이 여러명일 수 있기 때문에 이는 집단으로 표현해야 한다. 이를 액터(actor)라고 하자.
하나의 모듈은 하나의, 오직 하나의 액터에 대해서만 책임져야 한다.
모듈은 쉽게 소스파일이라 생각하면 된다. 만일 코드가 소스 파일에 저장되지 않는다면 모듈은 단순히 함수와 데이터 구조로 구성된 응집된 집합이다.
SRP를 위반하는 징후
우발적 중복
Employee 클래스에 calcutePay(), reportHours(), save()메서드가 있다. 이 클래스는 SRP 원칙을 위배한다.
•
calcutePay() : 회계팀에서 기능을 정의 ⇒ CFO에게 보고를 위해 사용
•
reportHours() : 인사팀에서 기능을 정의 ⇒ COO에게 보고를 위해 사용
•
save() : 데이터베이스 관리자가 기능을 정의 ⇒ CTO에게 보고를 위해 사용
이 상황에서 회계팀에서 결정한 사항이 인사팀이 의존하는 무언가에 영향을 줄 수 있다. 반대의 경우도 마찬가지.
만일, 두 메서드에서 초과 근무를 제외한 업무시간을 계산하는 알고리즘을 공유하고 이를 regularHours()라는 메서드에 넣었다고 하자. 이 때 회계팀에서 급여 계산을 위한 업무시간을 계산하는 방법을 바꾸기로 해서 regularHours()를 변경하면 인사팀은 의도하지 않은 업무시간 계산 방식의 변경에 의해 큰 혼란을 겪을 것이다.
병합
소스코드에 다양하고 많은 메서드를 포함하면 병합이 자주 발생할 것이다. 게다가 이들 메서드가 서로 다른 액터를 책임진다면 병합이 발생할 가능성은 확실히 더 높다.
