7장 SRP: Single Responsibility Principle 단일 책임 원칙

콘웨이 법칙에 따른 따름정리: 소프트웨어 시스템이 가질 수 있는 최적의 구조는 시스템을 만드는 조직의 사회적 구조에 영향을 받는다. 각 소프트웨어 모듈은 변경의 이유가 단 하나여야 한다.

단일 책임 원칙은 객체 지향 설계 원칙 중 하나로, 하나의 클래스는 하나의 책임만 가져야 한다는 것을 의미합니다. 즉, 클래스가 변경되어야 하는 이유는 오직 하나뿐이어야 한다는 것입니다. 이를 통해 클래스의 응집도(cohesion)가 높아지고 결합도(coupling)가 낮아져 유지보수와 확장성이 증가하게 됩니다.

 

SRP를 준수하는 코드는 각 클래스가 자신의 책임에 충실하고 다른 클래스와 관련 없는 기능이 없는 것이 특징입니다. 이를 위해서는 클래스의 책임을 명확히 분리하고, 각각의 책임이 변경될 때 다른 책임에 영향을 미치지 않도록 구현해야 합니다.

 

SRP를 잘 준수하면 코드의 가독성과 유지보수성이 향상되고, 코드의 재사용성과 확장성도 증가하게 됩니다.

 

모듈이 하나의 일만 해야 한다는 것이 아니라 함수가 하나의 일만 해야 한다는 것이다.

 

💡 단일 모듈은 변경의 이유가 하나뿐이어야 한다. = 하나의 모듈은 하나의 액터에 대해서만 책임져야 한다.

 

모듈
소스 파일, 함수 & 데이터 구조로 구성된 응집된 집합

 

징후 1: 우발적 중복

3개의 메서드가 서로 다른 액터를 책임진다.

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

메서드들을 단일 클래스에 배치하여 3개의 액터가 서로 결합되었다.

calculatePay 와 reportHours 에서 공통으로 호출하는 메서드 = regularHours() : 초과근무를 제외한 업무시간 계산하는 메서드

회계팀과 인사팀에서 업무시간을 계산하는 목적이 다르기 때문에 동작이 달라질 수 있다.

• 회계팀에서 계산 방식을 수정하는 경우, 인사팀과 계산 방식이 달라진다.
• 테스트는 통과하기 때문에 문제가 없다고 느끼지만, 실제 보고서에 포함된 값들이 잘못되게 된다.

SRP는 서로 다른 액터가 의존하는 코드를 서로 분리하라고 말한다.

징후 2: 병합

소스 파일에 다양하고 많은 메서드를 포함하면 병합이 자주 발생하리라고 짐작할 수 있다. 이들 메서드가 서로 다른 액터를 책임진다면 병합이 발생할 가능성은 확실히 더 높다.

같은 소스 파일을 서로 다른 목적으로 변경하는 경우에 병합이 발생한다.

서로 다른 액터를 뒷받침하는 코드를 서로 분리해야 한다.

해결책

메서드를 각기 다른 클래스로 이동시키는 방식

가장 확실한 해결책

데이터와 메서드를 분리하는 방식

• EmployeeData: 아무런 메서드가 없는 간단한 데이터 구조
• 3개의 클래스가 공유하도록 하고, 각 클래스는 자신의 메서드에 필요한 소스 코드만을 포함한다.
• 세 클래스는 서로의 존재를 몰라야 함

우연한 중복을 피할 수 있다.

 

이 해결책은 개발자가 세가지 클래스를 인스턴스화하고 추적해야 한다는 단점이 있다.

→ 퍼사드 패턴 적용

EmployeeFacade 에 코드는 거의 없다. 이 클래스는 세 클래스의 객체를 생성하고, 요청된 메서드를 가지는 객체로 위임하는 일을 책임진다.

가장 중요한 업무 규칙을 데이터와 가깝게 배치하는 방식으로 하고 싶은 경우

• 가장 중요한 메서드는 기존 Employee 클래스에 유지
• Employee 클래스를 덜 중요한 나머지 메서드들에 대한 퍼사드로 사용

결론

SRP : 메서드와 클래스 수준의 원칙

상위의 두 수준에서도 다른 형태로 다시 등장

 

컴포넌트 → 공통 폐쇄 원칙

아키텍처 → 아키텍처 경계의 생성을 책임지는 변경의 축

 

느낀점

내가 짠 코드들은 이 원칙을 지키고 있는가?를 생각해보게 되는 SOLID 원칙이다.

물론 그 전에는 이 원칙을 잘 알고 짜지 않았지만, 그래도 한번씩 되돌아보게 된다.

 

퍼사드 패턴을 적용해본적 없었는데, 이렇게 쪼개면 파일이 많아져서 불편하다고만 생각했지 퍼사드 패턴을 적용해볼 생각을 미처 못했어서 인상깊었다. 내가 그동안 디자인 패턴을 너무 어렵게 생각했던것 같다.