Clean Architecture_3부 정리

3부. 설계 원칙

Solid 원칙

• 함수와 데이터 구조를 클래스로 배치하는 방법, 그리고 이들 클래스를 서로 결합하는 방법을 설명
• SRP(단일 책임 원칙): 각 소프트웨어 모듈은 변경의 이유가 단 하나여야함
• OCP(개방 폐쇄 원칙): 기존 코드를 수정하기보다는 새로운 코드를 추가하는 방식으로 시스템의 행위를 변경할수 있도록 설계해야 시스템을 쉽게 변경할 수 있다.
• LSP(리코스프 치환 원칙): 상호 대체 가능한 구성요소를 이용해 소프트웨어 시스템을 만들 수 잇으려면, 이들 구성요소는 반드시 서로 치환 가능해야한다는 제약을 지켜야함
• ISP(인터페이스 분리 원칙): 소프트웨어 설계자는 사용하지 않은 것에 의존하지 않아야 한다.
• DIP(의존성 역전 원칙): 고수준 정책을 구현하는 코드는 저수준 세부사항을 구현하는 코드에 절대로 의존해서는 안된다. 대신 세부사항이 정책에 의존해야함

solid 원칙의 목적

• 변경에 유연하다
• 이해하기 쉽다
• 많은 소프트웨어 시스템에 사용될 수 있는 컴포넌트의 기반이 된다

 

7장. SRP: 단일 책임 원칙

단일 책임의 원칙

• 하나의 모듈은 오직 하나의 액터에 대해서만 책임져야한다.
  • 액터 : 해당 변경을 요청하는 한명 이상의 사람들
  • 모듈 : 소스 파일, 함수와 데이터 구조로 구성된 응집된 집합
• 단일 액터를 책임지는 코드를 함께 묶어주는 힘이 응집성

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

원칙을 위반하는 징후

1. 우발적 중복

서로 다른 액터가 의존하는 코드를 너무 가까이 배치하여 발생

• SRP는 서로 다른 액터가 의존하는 코드를 분리하라고 함

1. 병합

많은 사람들이 서로 다른 목적으로 동일한 소스 파일을 변경하는 경우 해당

• SRP는 서로 다른 액터가 의존하는 코드를 분리하라고 함

해결책

• 메서드를 각기 다른 클래스로 이동시키는 방법
• 데이터와 메서드를 분리하는 방법
  • 메서드가 없는 간단한 데이터 구조 클래스를 만들어 다른 클래스들이 공유하도록 함
  • 각 클래스는 메서드에 반드시 필요한 소스 콛만을 포함
  • 개발자가 클래스들을 인스턴스화하고 추적해야한다는 단점 존재
  • 퍼사드 패턴을 사용하여 해결

 

8장. OCP: 개방 폐쇄 원칙

개방 폐쇄 원칙

소프트웨어 개체는 확장에는 열려 있어야 하고, 변경에는 닫혀있어야함

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

아키텍트는 기능이 어떻게, 왜, 언제 발생하는지에 따라 기능을 분리하고, 분리한 기능을 컴포넌트의 계층 구조로 조직화

• 컴포넌트 계층구조를 조직화하면 저수준 컴포넌트에서 발생한 변경으로부터 고수준 컴포넌트를 보호 가능

목표 : 시스템을 확장하기 쉬운 동시에 변경으로 인해 시스템이 너무 많은 영향을 받지 않도록하는 데 있음

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

 

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

리코스프 치환 원칙

S 타입의 객체 o1 각각에 대응하는 T타입 객체 o2가 있고, T 타입을 이용해서 정의한 모든 프로그램 P에서 o2 의 자리에 o1을 치환하더라도 P의 행위가 변하지 않는다면, S는 T의 하위 타입이다.

• 상속관계에서 자식 클래스는 부모 클래스를 대체할 수 있어야함

LSP는 아키텍처 수준까지 확장할 수 있고, 반드시 확장해야함

치환 가능성을 조금이라도 위배하면 시스템 아키텍처가 오염되어 상당량의 별도 메커니즘을 추가해야 할 수 있기 때문

 

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

인터페이스 분리 원칙

클라이언트가 자신이 사용하지 않는 메서드에 즤존하지 않아야함

인터페이스를 작게 분리하고, 클라이언트가 필요한 메서드만을 인터페이스로 노출한다.

 

11장. DIP: 의존성 역전 원칙

의존성 역전 원칙

유연성이 극대화된 시스템 : 소스코드 의존성이 추상에 의존하며 구체에는 의존하지 않는 시스템

DIP를 따르면 소스 코드 의존성은 제어 흐름과 반대 방향으로 역전됨

안정된 추상화

추상 인터페이스에 변경이 생기면 이를 구체화한 구현체들도 따라서 수정해야함

원칙

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