[틈새 독서] 클린 아키텍쳐 <SOLID - SRP, OCP>

SOLID 원칙

목적

• 유연한 소프트웨어 구조 변경
• 이해하기 쉬운 소프트웨어 구조 설계
• 많은 소프트웨어 시스템에 사용될 수 있는 컴포넌트 설계의 기반

기원

• 2000년 초반 저자 (로버트 C 마틴)는 안정화된 원칙을 고안했으나, 2004년 무렵 마이클 페더스가 각 원칙을 재배열하면 SOLID라는 단어를 만들 수 있다해서 그렇게 했다 아 ㅋ

원칙 종류

• SRP : 단일 책임 원칙
  • 콘웨이 법칙에 따른 따른정리로, 소프트웨어 시스템이 가질 수 있는 최적 구조는 시스템을 만드는 조직의 사회적 구조에 커다란 영향을 받는 것이다. 따라서 각 소프트웨어 모듈은 변경 이유가 단 하나여야 한다.
• OCP : 개방-폐쇄 원칙
  • 버트란트 마이어에 의해 고안된 원칙, 기존 코드 수정보다는 반드시 새로운 코드를 추가하는 방식으로 시스템의 행위를 변경할 수 있도록 설계해야만 시스템이 유연해 진다는 것이 요지다.
• LSP : 리스코프 치환 원칙 
• - 1988년 바바라 리슼코프가 정의, 상호대체 가능한 구성요소를 이용해 소프트웨어 시스템을 만드려면, 이들 구성요소는 반드시 서로 치환 가능해야 한다.
• ISP : 인터페이스 분리 원칙

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

• DIP : 의존성 역전 원칙

    - 고수준 정책을 구현하는 코드는 저수준 세부사항을 구현하는 코드에 절대 의존하면 안된다. 대신 세부사항이 정책에 의존해야 한다. (구체화된 인터페이스가)

---

SRP

주의사항

• 대부분 이름만 보고 각 모듈이 하나의 일만 해야한다고 이해하곤 한다.
• 하지만, 위 원칙은 함수는 각기 하나의 역할만 해야한다는 원칙으로 다른 원칙으로 SOLID에 포함되지 않는다.

SRP 재해석

• SRP에서 말하는 '변경의 이유'는 사용자 (이해관계자, 집단, 액터)의 관점에서 발생하는 것이다.
• 하나의 모듈은 오직 하나의 액터에 대해서만 책임져야 한다.

그럼 모듈이란 무엇인가?

• 단일 액터를 책임지는 코드들을 응집시키는 응집성이 존재하면, 해당 코드들은 하나의 모듈로 묶을 수 있다.
• 이런 응집성을 확인하는 방법은 아래와 같은 징후를 보면 안다.
  1. 우발적 중복 (급여 시스템 Employee 예시)
  • 하나의 클래스에서 서로 다른 액터에 대해 처리하는 함수를 갖는다.
  • 이런 경우, 각각의 액터 전용으로 함수를 따로 빼는 것이 차후 기능 간섭을 우회할 수 있는 좋은 방법이다.
  2. 병합
  • 서로 다른 액터가 같은 클래스를 공유하고 이 액터들을 처리하기 위해 함수를 개별화 하지 않으면, 이 코드를 수정하는 서로 다른 개발자들이 병합을 할 때 큰 이슈가 생길 것 이다.

OCP : 개방-폐쇄 원칙

1988년 버트란트 마이어가 제시

• 소프트웨어 개체는 확장엔 열리고 변경엔 닫혀야 한다.

사고실험

• 로버트.C.마틴은 사고실험에서 [View, Presenter, Controller, Interactor, Database]라는 컴포넌트를 이용해 아키텍트 내 컴포넌트를 계층구조화하는 방법과 컴포넌트간 의존과 의존에 의한 변경사항으로 부터 보호 받을 수 있음을 보여줬다.

방향성 제어

• 로버트.C.마틴의 책 내 그림 8.2에 보면 각 모듈과 모듈 사이의 소통 창구로써 인터페이스가 하나씩 배치되어 있는 것을 알 수 있다. (Gateway, Presenter, View)
• 해당 인터페이스를 통해 의존성 역전을 수행하고 이를 통해 각 모듈간 서로 침범없이 깨끗하게 소통할 수 있다.

정보 은닉

• 반면 FinancialReportRequester는 방향성제어와는 다른 목적을 갖는 인터페이스다.
• 해당 인터페이스는 ReportController가 Interactor 내부에 대해 알아야 할 정보만 제공하기 위해 (정보은닉을 위해) 존재한다. 만약 이게 없었다면, Controller는 FinancialEntities에 대해 추이 종속성을 갖게 된다.(A->B, B->C면 A->C인 것을 추이 종속성이라 한다.)