[Clean Architecture 정리] 7장. SRP

설계 원칙

- SOLID 원칙은 함수와 데이터 구조를 클래스로 배치하고 클래스 간 결합하는 방법

- 여기서 클래스는 객체 지향 프로그래밍에서 말하는 클래스 이상의 의미를 가진 함수와 데이터를 결합한 집합

- SOLID 원칙의 목적은 중간 수준의 소프트웨어 구조가 '변경에 유연하고', '이해하기 쉽고', '많은 SW 시스템에 사용될 수 있는 컴포넌트의 기반'이 되는데 목적을 둔다.

- '중간 수준'이라고 하면 코드 수준보다는 상위에서 적용되며 모듈과 컴포넌트 내부에서 사용되는 SW 정의하는데 도움을 준다는 의미

 

 

SOLID

단일 책임 원칙(SRP, Single Responsibility Principle)

- 각 소프트웨어 모듈은 변경의 이유가 단 하나

 

 

개방-폐쇄 원칙(OCP, Open-Closed Principle)

- 기존 코드를 수정하기보다는 반드시 새로운 코드를 추가하는 방식으로 시스템의 행위를 변경할 수 있도록 설계해야만 쉽게 변경 가능

 

 

리스코프 치환 원칙(LSP, Liskov Substitution Principle)

- 상호 대체 가능한 구성요소를 이용해 SW 시스템을 만들 수 있으려면, 구성요소는 반드시 서로 치환 가능해야한다

 

 

인터페이스 분리 원칙(ISP, Interface Segregation Principle)

- 사용하지 않는 것에 의존하지 않아야 한다.

 

 

의존성 역전 원칙(DIP, Dependency Inversion Principle)

- 고수준 정책을 구현하는 코드는 저수준 세부사항을 구현하는 코드에 절대로 의존해서는 안된다.

- 세부사항이 정책에 의존해야 한다.

 

 

단일 책임 원칙(SRP)

- 단일 모듈은 단 하나의 책임을 가져야 한다.

- '단 하나의 책임'이란 말은 '단 하나의 일'이란 의미보다는 단 하나의 변경 이유'로 해석하는 것이 적절하다

- 역사적으로 SRP는 "단일 모듈은 변경의 이유가 하나, 오직 하나뿐이어야 한다"

- 클린 아키텍처에서 SRP는 "하나의 모듈은 하나의, 오직 하나의 액터에 대해서만 책임져야 한다"고 서술되어 있다.

 

 

SRP를 위반하는 징후 

우발적 중복

Employee 클래스

- 클린 아키텍처에 나온 예제

- Employee 클래스는 CFO, COO, CTO 서로 다른 세 그룹의 액터를 가진다

- calculatePay() : 회계팀에서 기능 정의. CFO 보고를 위해 사용

- reportHours() : 인사팀에서 기능 정의. COO 보고를 위해 사용

- save() : DBA가 기능 정의. CTO 보고를 위해 사용

 

- calculatePay 함수와 reportHours 함수는 근무 시간을 계산하는 알고리즘이 필요하고 코드 중복을 피하기 위해 regularHour() 라는 메서드로 정의

- 이 때, CFO에서 초과 근무 시간을 계산하기 위해 regularHours() 메서드의 로직을 변경했다고 하면, 그 여파는 COO에서 정의했던 reportHours() 메서드까지 영향을 미친다

 

 

 

병합

- 위 예제에서, 서로 다른 세 개발자가 각 액터를 책임지고 기능을 개발한다고 가정하자

- 각 개발자는 액터로부터 요구사항을 받고 개발을 진행하면서 변경 사항을 적용하기 시작하면 이들의 변경 사항은 계속해서 충돌할 것이다

- 소스 코드를 병합하기 위한 좋은 환경들이 존재하지만 병합이 발생하는 모든 경우를 해결할 수는 없다.

 

 

해결책

- 앞에서 살펴본 SRP를 위반했을 때 발생하는 징후들은 다른 액터가 의존하는 코드를 너무 가까이 배치했기 때문이다.

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

 

데이터와 메서드를 분리

 

- 단순히 데이터 구조 역할을 하는 클래스를 만들어 서로 다른 기능을 수행하는 클래스들이 공유하도록 하는 방법

- 각 클래스는 필요한 기능만을 소스 코드에 포함하고, 서로의 존재를 몰라야 한다.

- 데이터와 메서드를 분리함으로써 '우연한 중복'을 피할 수 있다.

 

 

 

Facade Pattern

- 단순히 데이터와 메서드를 분리하는 방식의 단점은 개발자가 각 클래스를 인스턴스화하고 추적해야한다는 점이다.

- Facade Pattern을 이용해 Facade 클래스에 객체 생성에 대한 책임을 부여하고, 실제 기능 수행은 각 클래스에 위임하는 방식을 사용할 수 있다.

 

 

단일 책임 원칙(SRP, Single Responsibility Principle)

- 단일 책임 원칙은 메서드와 클래스 수준의 원칙이다.

- 컴포넌트 수준에서 '공통 폐쇄 원칙(Common Closure Principle)', 아키텍처 수준에서 '아키텍처 경계(Architectural Boundary)의 생성을 책임지는 변경의 축(Axis of Change)'의 형태로 SRP의 개념은 적용될 수 있다.

 

서적 : http://www.yes24.com/Product/Goods/77283734

클린 아키텍처 - YES24