💡 개방 - 폐쇄 원칙

개방 - 폐쇄 원칙이란

<aside> 💡 소프트웨어 개체는 확장에는 열려 있어야 하고, 변경에는 닫혀 있어야 한다는 원칙

</aside>

• 소프트웨어 개체의 행위는 확장 할 수 있어야 하지만, 개체를 변경 해서는 안됨
• 만약, 특정 모듈 ( 클래스 )에 수정을 가할때, 모듈을 이용하는 다른 모듈을 줄줄이 고쳐야 한다면 수정하는 것이 쉽지 않음
• 시스템의 구조를 올바르게 리팩토링 하여 변경이 더이상의 수정을 유발하지 않도록 하는 것
• 기능을 추가하거나, 변경해야 할 때, 이미 제대로 동작하고 있는 코드를 변경 하지 않아도 됨
• 즉, 변경으로 인해 시스템이 많은 영향을 받지 않는 것이 최대의 목표
• 시스템을 컴포넌트 단위로 분리하고, 저수준 컴포넌트 ( ex_ view ... )에서 발생한 변경으로 부터 고수준 컴포넌트 ( ex_ interactor ... )를 보호 할 수 있는 형태의 의존성 계층 구조를 만드는 것이 최대 목표

개방 - 폐쇄 원칙을 지키는 방법

• 변화하는 부분을 추상화 하라
  • interface / abstract class를 활용하여, 클래스의 구체적인 부분을 활용하여 서로 의존되는 것이 아니라, 추상화 된 부분에 의존 하도록 둠
• 상속을 활용하여, 변경이 일어나는 부분을 자식 클래스에만 두어라 ( 자식 → 부모로 향하는 의존성이 분리되는 것을 활용 )

지키지 않았을 때의 문제점

• 학교 반 청소 추상화 예시 에서, Student 클래스를 Cleaning Crew interface를 활용하여 추상화 하기 전에, Teacher 클래스가 Student의 타입에 의존 하는 경우
• 위 경우, 새로운 Student가 추가 되었을 때, Teacher 클래스의 함수를 변경 해 주어야 함

보호의 계층 구조가 생기는 원리

• A컴포넌트로 발생한 변경으로 부터 B컴포넌트를 보호하려면, 반드시 A 컴포넌트가 B 컴포넌트에 의존 해야 함
  • View 컴포넌트로부터 ViewModel 컴포넌트를 보호하려면, View 컴포넌트가 ViewModel 컴포넌트에 의존 해야 함
• 가장 중요한 문제를 다루는 컴포넌트가 있다면, 이 컴포넌트를 다른 컴포넌트의 변경으로 부터 독립 시켜야 함
  • 책에서는, Interactor가 비즈니스로직을 다루는 것으로 나오는데, 이러한 컴포넌트를 다른 컴포넌트로 부터 독립 시켜야 한다고 말하는 것
  • 따라서 책에서는, Interactor를 OCP를 가장 잘 준수 할 수 있는 곳에 위치 시킴 ( DB / View / Presenter / Controller 의 구체적인 변경에 영향을 받지 않는 곳으로 )
• Interactor와 DB가 서로 소통하기 위해 중간 Interface를 두고, 이를 실제로 구현한 DB Mapper를 둠으로써 DB와 Interactor의 의존성을 완전리 분리 시켜 줌
• Interactor와 Controller 사이에 interface를 둠으로써, controller가 interactor에 너무 많은 것을 알지 않도록 정보 은닉도 시킬 수 있음 → 추이 종속성을 제거 할 수 있음
  • 추이 종속성 : A클래스가 B클래스에 의존, B클래스가 C클래스에 의존한다면 A 클래스가 C클래스에 의존하게 되는 것
  • 이때, C클래스가 A클래스에 의존하게 된다면 순환 의존성이 발생하며, 이는 심각한 문제를 야기 할 수 있음