• SOLID 원칙 중에서 그 의미가 가장 잘 전달되지 못한 원칙은 바로 단일 책임 원칙

• 부적절한 이름 때문에 모든 모듈이 단 하나의 일만 해야 한다는 의미로 받아들이기 쉽다

• 단 하나의 일만 해야 한다는 원칙은 사실 따로 있고, 그것은 함수는 반드시 하나의 일만 해야한다는 원칙

• SRP의 원칙은 다음과 같다

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

• 소프트웨어 시스템은 사용자와 이해관계자를 만족시키기 위해 변경

• SRP가 말하는 '변경의 이유'란 바로 이들 사용자와 이해관계자를 가리킨다

• 원칙은 아래와 같이 바꿔 말할 수도 있다

  하나의 모듈은 하나의, 오직 하나의 사용자 또는 이해관계자에 대해서만 책임져야 한다
  

• 시스템이 동일한 방식으로 변경되기를 원하는 사용자나 이해관계자가 두 명 이상일 수도 있다

• 그래서 집단, 즉 해당 변경을 요청하는 한 명 이상의 사람들, 액터(actor)라고 부르고, 최종 버전은 아래와 같다

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

• '모듈'이란 대부분의 경우 소스 파일을 의미하며, 일부 언어와 개발 환경에서는 단순히 함수의 데이터 구조로 구성된 응집된 집합

• '응집된(cohesive)'이라는 단어가 SRP를 암시. 단일 액터를 책임지는 코드를 함께 묶어주는 힘이 바로 응집성(cohesion)

• 이 원칙을 이해하는 가장 좋은 방법은 이 원칙을 위반하는 징후들을 살펴보는 일

징후 1: 우발적 중복

• 그림 7.1 Employee 클래스
• 위의 사례는 급여 애플리케이션의 Employee 클래스
• 해당 클래스는 calcuatePay(), reportHours(), save()를 가진다
• SRP를 위반하는데, 이들 세 가지 메소드가 서로 매우 다른 세명의 액터를 책임지기 때문
  1. calculatePay() 메소드는 회계팀에서 기능을 정의하며, CFO 보고를 위해 사용
  2. reportHours() 메소드는 인사팀에서 기능을 정의하고 사용하며, COO 보고를 위해 사용
  3. save() 메소드는 데이터베이스 관리자(DBA)가 기능을 정의하고, CTO 보고를 위해 사용
• 개발자가 이 세 메소드를 단일 클래스에 배치하여 세 액터가 서로 결합되어 버렸다
• 이 결합으로 CFO 팀에서 결정한 조치가 COO 팀이 의존하는 무언가에 영향을 줄 수 있다
• 예를 들어 calculatePay() 메소드와 reportHours() 메소드가 초과 근무를 제외한 업무 시간을 계산하는 알고리즘을 공유한다고 가정