Clean Architecture - SOLID 원칙

SOLID 원칙은 함수와 데이터 구조를 클래스로 배치하는 방법, 그리고 이 클래스들을 서로 결합하는 방법을 설명해준다. 여기서 클래스는 함수와 데이터를 결합한 집합을 가리킨다. SOLID 원칙의 목적은 소프트웨어 구조가 다음과 같도록 만드는데 있다. 

 

- 변경에 유연하다

- 이해하기 쉽다

- 많은 소프트웨어 시스템에 사용될 수 있는 컴포넌트의 기반이 된다.

 

아래는 이들 SOLID원칙을 이루는 원칙들에 대한 개략적인 설명이다. 

 

 

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

: 각 소프트웨어 모듈은 변경의 이유가 단 하나여야만 한다. 서로 다른 사용자가 의존하게 되는 코드를 분리하는 것이 핵심. 

 

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

: 기존 코드를 수정하기보다는 반드시 새로운 코드를 추가하는 방식으로 시스템의 행위를 변경할 수 있도록 설계해야만 소프트웨어 시스템을 쉽게 변경할 수 있다는 것이 원칙의 요지이다. 이는 시스템을 확장하기 쉬운 동시에 변경으로 인해 시스템이 너무 많은 영향을 받지 않도록 하는데에 있다.

 

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

: 하위 타입에 관해 유명한 원칙. 상호 대체 가능한 구성요소를 이용해 소프트웨어 시스템을 만들 수 있으려면, 이들 구성요소는 반드시 서로 치환 가능해야 한다는 계약을 반드시 지켜야한다.  LSP를 위반하는 대표적인 문제로는 정사각형/직사각형 문제가 있다. 

 

- ISP (Interface segregation Principle) 인터페이스 분리 원칙 

: 소프트웨어 설계자는 사용하지 않은 것에 의존하지 않아야 한다.

 

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

 : 고수준 정책을 구현하는 코드는 저수준 세부사항을 구현하는 코드에 절대로 의존해서는 안된다. 대신 세부사항이 정책에 의존해야한다. 즉, '추상'에 의존하며 변동성이 큰 '구체적인 요소'에 의존하지 않고 피하고자 하는 시스템을 의미한다. 추상 컴포넌트는 모든 고수준의 작업 규칙을 포함하고, 구체 컴포넌트는 업무규칙을 다루기 위해 필요한 모든 세부사항을 포함한다. 

 다음은 DIP를 위한 구체적인 코딩 실천법이다. 
  1, 변동성이 큰 구체 클래스를 참조하지 말라. 

  2. 변동성이 큰 구체 클래스로부터 파생하지 말라

  3. 구체 함수를 오버라이드 하지 말라.

  4. 구체적이며 변동성이 크다면 절대로 그 이름을 언급하지 말라

 

 

 

 

적용

: 코딩하며 무언가 코드의 재사용성과 의존성에 관련하여 무언가 불편한 점이 있었는데 그게 명확해졌다.

예를 들어 성경필사 앱을 만들고 DB를 관리할 때에 CRUD와 관련된 Class를 하나하나 구체화 시켜 만들면서 무언가 불편했는데 이 부분부터 수정해봐야겠다. 

읽으면서 드는 생각은 Protocol을 적극적으로 활용하면 위의 원칙들을 보다 적절하게 지킬 수 있지 않을까? 
Clean Architecture을 적용한 코드들의 예를 좀 찾아봐야겠다.