클린 아키텍처 - 설계원칙 - SRP

설계원칙

SOLID

• SRP: 단일 책임 원칙 Single Responsible Principle
• OCP: 개방-폐쇄 원칙 Open-Closed Principle
• LSP: 리스코프 치환 법칙 Liskov Substitution Principle
• ISP: 인터페이스 분리 원칙 Interface Segregation Principle
• DIP: 의존성 역전 원칙 Dependency Inversion Principle

SRP

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

• 모든 모듈이 단 하나의 일만 해야 한다는 의미는 아니다.
• 응집된(cohesive)라는 단어가 SRP를 암시한다.
• 이 원칙을 위반하는 징후들을 살펴 보겠다.

---

징후 1: 우발적 중복

[그림 1-1 Employee 클래스]

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

[그림 1-2 공유된 알고리즘]

• CFO 팀에서 초과 근무를 제외한 업무 시간을 계산하는 방식을 약간 수정했고, COO 조직에서는 다른 목적에 같은 메쏘드를 이용했다면, 잘못된 계산이 되어 버린다.
• 이러한 문제는 서로 다른 관계자가 의존하는 코드를 너무 가까이 배치했기 때문에 발생한다. _SRP_는 서로 다른 관계자가 의존하는 코드를 서로 분리하라고 말한다.

---

징후 2: 병합

• CTO 조직의 DBA가 Employee 테이블 스키마를 약간 수정했다고 치자. 이와 동시에 인사 담당자가 속한 COO 팀에서는 reportHours() 메서드의 보고서 포맷을 변경하기로 결정했다고 해 보자.
• 서로 다른 조직의 어쩌면 얼굴도 모르는 두 개발자가 클래스를 checkout 한 뒤에 변경사항을 적용하기 시작한다. 안타깝게도 이들 변경사항이 서로 충돌(conflict)된다.

---

해결책

• 여러가지 해결책이 있겠지만 가장 확실한 해결책은 데이터와 메서드를 분리하는 방식일 것이다. 즉, 아무런 command 가 없는 value object를 만들어 공유하는 것이다.

[그림 1-3 세 클래스는 서로의 존재를 알지 못한다.]

---

• 반면 이 해결책은 개발자가 세 가지 클래스를 인스턴스화하고 추적해야 한다는게 단점이다. 이러한 난관에서 빠져나올 때 흔히 쓰는 기법으로 파사드 패턴이 있다.

[그림 1-4 파사드(Facade) 패턴]

결론

• 단일 책임 원칙은 메서드와 클래스 수준의 원칙이다. 하지만 이보다 상위의 두 수준에서도 다른 형태로 다시 등장한다. 컴포넌트 수준에서는 공통 패쇄 원칙 _Common Closure Principle_이 된다.

 

 

클린 아키첵처 전체 보기 

클린 아키텍처란? https://blog.kjslab.com/199
클린 아키텍처 - 설계원칙 - SRP https://blog.kjslab.com/200 
클린 아키텍처 - 설계원칙 - OCP https://blog.kjslab.com/201 
클린 아키텍처 - 설계원칙 - LSP https://blog.kjslab.com/202 
클린 아키텍처 - 설계원칙 - ISP https://blog.kjslab.com/203  
클린 아키텍처 - 설계원칙 - DIP & SOLID 요약 https://blog.kjslab.com/204 
클린 아키텍처 - 컴포넌트 https://blog.kjslab.com/205 
클린 아키텍처 - 컴포넌트 결합 - ADP https://blog.kjslab.com/206   
클린 아키텍처 - 컴포넌트 결합 - SDP https://blog.kjslab.com/207
클린 아키텍처 - 컴포넌트 결합 - SAP & 결론 https://blog.kjslab.com/208