open and closed

확장에 대해선 열려있고 변경에 대해선 닫혀있다
확장 : 새로운 타입을 추가함으로써 새로운 기능을 추가하는 것
닫힘 : 상위 레벨 정책은 변경되면 안됨
OCP를 지키면 소스 코드 변경 없이 모듈의 행위를 쉽게 변경할 수 있다
추상화와 제어 역전을 하면 된다. 의존성 역전을 위해 추상 인터페이스를 주입한다. 상위 레벨 모듈은 의존성 주입이 되었으니 하위 레벨 모듈이 수정되어도 영향이 없다.
만약 기능이 확장될 때마다 if문으로 분기를 한다면 계속해서 수정(fragile)해야 한다. 확장이 필요한 행위를 추상화한다.

OCP가 가능한 것인가?

• OCP를 준수하면 수정을 완벽하게 제거할 수 있나?
  • 이론적으로난 가능하지만 비실용적
• 2가지 문제
  • main partition
  • 미래를 예측할 수 없다. 확장이 될만한 모든 곳에 인터페이스를 넣을 순 없다.

the lie

• 새 기능을 요구하면 대책이 없다. 미리 알았다면 OCP를 준수하도록 추상화를 했을텐데, 그러나 OCP는 어떤 확장이 필요할지 알아야만 제대로 할 수 있는건가? OCP는 미래를 완전히 예측할 수 있는 경우에만 지킬 수 있다.
  이를 해결하기 위한 방법 Big Design Up Front
• 조심스럽게 고객과 문제 영역을 고찰
• 요구사항을 예측하여 도메인 모델을 만든다
• OCP가 가능하도록 도메인 모델에 추상화를 적용한다
• 변경될 가능성이 있는 모든 것들에 대한 청사진을 얻을 때까지 헛된 짓을 계속한다
• 문제
  • 대부분의 경우 필요하지 않은 추상화로 도배된 매우 크고 무겁고 복잡한 쓰레기 설계를 만든다
  • 추상화는 유용하고 강력한 만큼 비용도 크다

agile design

• 최대한 빨리 고객의 요구사항을 끌어낼 수 있는 가장 단순한 일을 한다
• 고객은 결과물에 대해 요구사항 변경을 시작하고 어떤 변경이 요구되는지 알게 된다.

완벽하게 지키는 건 불가능하지만 OCP를 준수함으로써 변경을 최소화할 수 있다.
OCP는 시스템 아키텍쳐의 핵심이다.