[Clean Architecture] 3부 설계 원칙: SOLID

SOLID 원칙은 함수와 데이터 구조를 클래스로 배치하는 방법, 그리고 이들 클래스를 서로 결합하는 방법을 설명해준다.

SOLID 원칙의 목적은 변경에 유연한, 이해하기 쉬운, 많은 소프트웨어 시스템 컴포넌트의 기반이 되는 소프트웨어 아키텍처를 만들고자 함.

 

7장 SRP: 단일 책임 원칙

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

 

1. 원칙을 위반하는 징후 1: 우발적 중복

하나의 컴포넌트에 대한 변경 사항이 다른 컴포넌트에도 영향을 미치는 문제.

SRP는 서로 다른 액터(변경을 요하는 집단)가 의존하는 코드를 각각 분리시키라고 말한다.

 

2. 원칙을 위반하는 징후 2: 병합

둘 이상의 사람이 서로 다른 목적으로 동일한 소스 파일을 변경하는 경우 병합(충돌)이 발생한다.

 

해결책

메서드를 각기 다른 클래스로 이동시키는 방식 사용. 데이터와 메서드를 분리한다.

퍼사드(Facade) 패턴

 

8장 OCP: 개방-폐쇄 원칙

소프트웨어 개체의 행위는 확장할 수 있어야 하지만, 이때 개체를 변경해서는 안 된다는 원칙.

 

서로 다른 목적으로 변경되는 요소를 적절하게 분리하고(SRP: 단일 책임 원칙), 이들 요소 사이의 의존성을 체계화함으로써(DIP: 의존성 역전 원칙) 코드 변경량을 최소화할 수 있다.

A 컴포넌트를 변경함에 있어 B 컴포넌트를 보호하려면 반드시 A 컴포넌트가 B 컴포넌트에 의존해야 한다.

 

아키텍트는 목적에 따라 기능을 분리하고, 분리한 기능을 컴포넌트의 계층구조로 조직화한다.

OCP의 목표를 달성하기 위해서는 시스템을 컴포넌트 단위로 분리하고, 저수준 컴포넌트에서 발생한 변경으로부터 고수준 컴포넌트를 보호할 수 있는 형태의 의존성 계층구조가 만들어지도록 해야 한다.

 

9장 LSP: 리스코프 치환 원칙

상호 대체 가능한 구성 요소를 이용해 소프트웨어 시스템을 만들려면, 이들 구성 요소는 반드시 서로 치환 가능해야 한다는 원칙.

치환 가능성을 위배하면 상당량의 별도 메커니즘을 추가해야 할 수도 있다.

 

10장 ISP: 인터페이스 분리 원칙

객체는 자신이 호출하지 않은 메서드에 대해 의존하지 않아야 한다는 원칙.

객체가 반드시 필요한 기능만을 가지도록 제한하는 원칙이다. 큰 규모의 객체는 인터페이스로 잘게 나누어 확장성을 향상시킨다.

 

11장 DIP: 의존성 역전 원칙

소스 코드 의존성은 추상(abstraction)에 의존하며 구체(concretion)에는 의존하지 않아야 한다는 원칙.

 

인터페이스는 구현체보다 변동성이 낮다.

즉, 안정된 소프트웨어 아키텍처란 변동성이 큰 구현체에 의존하는 일은 지양하고, 추상 인터페이스를 참조하는 아키텍처를 뜻한다.

 

• 변동성이 큰 구체 클래스를 참조하지 말라
• 변동성이 큰 구체 클래스로부터 파생하지 말라
• 구체 함수를 오버라이드 하지 말라
• 구체적이며 변동성이 크다면 절대로 그 이름을 언급하지 말라