OCP:개방-폐쇄 원칙

Gooreum·2021년 10월 28일
0

클린아키텍처

목록 보기
8/33

_'소프트웨어 개체(artifact)는 확장에는 열려 있어야 하고, 변경에는 닫혀 있어야 한다.'

  • 소프트웨어 개체의 행위는 확장할 수 있어야 하지만, 이때 개체를 변경해서는 안된다.
  • OCP의 목표는 시스템을 확장하기 쉬운 동시에 변경으로 인해 시스템이 너무 많은 영향을 받지 않도록 하는 데 있다.
    • 이러한 목표를 달성하려면 시스템을 컴포넌트 단위로 분리하고, 저수준 컴포넌트에서 발생한 변경으로부터 고수준 컴포넌트를 보호할 수 있는 형태의 의존성 계층구조가 만들어지도록 해야 한다.
  • 소프트웨어 아키텍처를 공부하는 가장 근본적인 이유가 바로 이 때문임.

사고 실험

  • 재무제표를 웹 페이지로 보여주는 시스템이 있다.
    • 새로운 요청 : 이해관계자가 동일한 재무제표 정보를 보고서 형태로 변환해서 흑백 프린터로 출력 해달라는 새로운 요청을 한다.
    • 어떻게 하면 될까?
      • (1) 단일 책임 원칙(SRP) 적용 : 서로 다른 목적으로 변경되는 요소를 적절하게 분리한다.

        이미지 출처 : https://wedonttalknemore.tistory.com/14?category=967824

      • 여기서 가장 중요한 것은 보고서 생성이 두 개의 책임으로 분리된다는 사실이다.

        • financial analyzer(재무 분석기) : 보고서용 데이터를 계산하는 책임
        • Web Reporter / Print Reporter : 이 데이터를 웹으로 보여주거나 종이로 프린트하기에 적합한 형태로 표현하는 책임
      • (2) 의존성 역전 원칙(DIP) 적용 : 이들 요소 사이의 의존성을 체계화함으로써 변경량을 최소화할 수 있다.

        • 책임을 분리하면 두 책임 중 하나에서 변경이 발생하더라도 다른 하나는 변경되지 않도록 소스 코드 의존성도 확실히 조직화해야 한다.
        • 또한 새로 조직화한 구조에서는 행위가 확장될 때 변경이 발생하지 않음을 보장해야 한다. → 처리 과정을 클래스 단위로 분할하고, 이들 클래스를 아래 그림에서 이중선으로 표시한 컴포넌트 단위로 구분해야 한다. 이미지 출처 : https://wedonttalknemore.tistory.com/14?category=967824
          • 클래스 설명
            • I : 인터페이스
            • DS : 데이터 구조
            • 열린 화살표 : 사용(Using) 관계
            • 닫힌 화살표 : 구현(implement) 관계 또는 상속(inheritance) 관계
        • 2가지 주목할 점 (1) 모든 의존성이 소스 코드 의존성을 나타낸다는 사실이다.
          • 화살표가 A 클래스에서 B 클래스로 향한다면, A 클래스에서는 B 클래스를 호출하지만 B 클래스에서는 A 클래스를 전혀 호출하지 않음.

            (2) 이중선은 화살표와 오직 한 방향으로만 교차한다.

          • 모든 컴포넌트 관계는 단 방향으로 이루어진다.

          • 이들 화살표는 변경으로부터 보호하려는 컴포넌트를 향하도록 그려진다.
            - A 컴포넌트에서 발생한 변경으로부터 B 컴포넌트를 보호하려면 반드시 A 컴포넌트가 B 컴포넌트에 의존해야 한다.

            이미지 출처 : https://wedonttalknemore.tistory.com/14?category=967824

          • 여기서는 Presenter에서 발생한 변경으로부터 Controller를 보호하고자 한다.

          • View에서 발생한 변경으로부터 Presenter를 보호하고자 한다.

          • Interactor는 다른 모든 것에서 발생한 변경으로부터 보호하고자 한다.

          • Interactor는 OCP를 가장 잘 준수할 수 있는 곳에 위치한다.

        • Interactor는 이처럼 왜 특별한 위치에 있어야 하는가?
          • Interactor가 업무 규칙을 포함하기 때문이다. (가장 중요한 문제는 Interactor가 담당)
          • Interactor는 애플리케이션에서 가장 높은 수준의 정책을 포함한다. 다른 컴포넌트들은 모두 주변적인 문제를 처리한다.
          • Interactor 입장에서 Controller는 부수적이지만 , Controller는 Presenter와 View에 비해서는 중심적인 문제를 담당한다. (마찬가지로 Presenter > View)
        • 컴포넌트 수준(level)
          • 이처럼 컴포넌트 보호의 계층구조가 생김으로써 각 컴포넌트의 수준이 정해진다.
          • Interactor: 가장 높은 수준의 개념 → 최고의 보호를 받음
          • View : 가장 낮은 수준의 개념 → 거의 보호를 받지 못함
          • Presenter : View 보다는 높고, Controller나 Interactor 보다는 낮은 수준
      • 아키텍처 수준에서 OCP가 동작하는 방식

        • 이러한 보호의 계층 구조는 아키텍처 수준에서 OCP가 동작하는 방식을 보여준다.
        • 아키텍트는 기능이 어떻게(how), 왜why, 언제when 발생하는지에 따라서 기능을 분리하고, 분리한 기능을 컴포넌트의 계층구조로 조직화한다.
        • 컴포넌트 계층구조를 이와 같이 조직화하면 저수준 컴포넌트에서 발생한 변경으로부터 고수준 컴포넌트를 보호할 수 있다.

방향성 제어

  • FinancialDataGateway 인터페이스는 FinancialReportGenerator와 FinancialDataMapper 사이에 위치. → 의존성을 역전시키기 위함.
    FinancialDataGateway 인터페이스가 없었다면 의존성이 Interactor 컴포넌트에서 Database 컴포넌트로 바로 향하게 된다.

정보 은닉

  • FinancialReportRequester 인터페이스는 방향성 제어와는 다른 목적을 가짐.
  • 이 인터페이스는 FinancialReportController가 Interactor 내부에 대해 너무 많이 알지 못하도록 막기 위해 존재.
  • 만약 이 인터페이스가 없었다면, Controller는 FinancialEntities에 대해 추이 종속성(transtive dependency)을 가지게 된다.
    • 추이 종속성을 가지게 되면, 소프트웨어 엔티티는 '자신이 직접 사용하지 않는 요소에는 절대로 의존해서는 안 된다'는 소프트웨어 원칙을 위반하게 된다.
  • Controller에서 발생한 변경으로부터 Interactor를 보호하는 일의 우선순위가 가장 높지만, 반대로 Interactor에서 발생한 변경으로부터 Controller도 보호되기를 바란다. 이를 위해 Interactor 내부를 은닉한다.
profile
하루하루 꾸준히

0개의 댓글