[클린 소프트웨어] PART 2 - CHAPTER 9 - 개방 폐쇄 원칙(OCP)

소프트웨어 개체(클래스, 모듈, 함수 등)는 확장에 대해 열려 있어야 하고, 수정에 대해서는 닫혀 있어야 한다.

 

OCP; Open-Closed Principle

OCP를 따르는 모듈은 다음과 같은 두 가지 속성을 갖는다.

1. Open: 확장에 대해 열려있다. 요구사항이 변경될 때, 이 변경에 맞개 새로운 행위를 추가해 모듈을 확장할 수 있다.
2. Close: 수정에 대해 닫혀있다. 모듈의 행위를 확장하는 것이 그 모듈의 소스코드 변경을 초래하지 않는다. 

하나의 변경이 의존적인 모듈에서 단계적인 변경을 초래할 때 경직성의 악취를 풍긴다. OCP에서는 이후 일어날 변경이 더 시앙의 수정을 유발하지 않도록 하라고 충고한다. 이미 제대로 동작하고 있던 원래 코드를 변경하는 것이 아닌 새로운 코드를 덧붙임으로써 요구사항 변경에 대응한다. 👉 해결책은 추상화!!

 

이건 OCP를 따르지 못함!!

이렇게 Client 클래스가 바로 Server  클래스를 바로 사용하는 경우 OCP를 따르지 못한다. Client가 다른 Server 객체를 사용하게 하기 위해서는 Client 클래스의 코드를 변경해야 하기 때문이다. 

 

OCP를 따름(참고로 Strategy Pattern)

이렇게 Client가 추상화된 Client Interface를 사용하게 바꾸면 새로운 Server 객체를 사용하고 싶을 때 Client Interface의 새로운 서브타입을 생성하면 된다. 

 

그렇다면 모든 변경을 예측하고 완벽하게 추상화해야 하는가? 

폐쇄는 완벽할 수 없다. 우리들이 경험으로 얻은 통찰력을 동원해도 닫혀 있지 않은 모듈에 대한 변경은 발생할 수 있다. 또한 OCP를 따르자면 비용이 많이 든다. 적절한 추상화를 만들기 위해서는 개발 시간과 노력이 많이 들 뿐만 아니라, 소프트웨어 설계의 복잡성을 높이기도 한다. 

따라서 이 책에서는 처음부터 완벽하게 변경을 예측하고 추상화하기 보다는 처음에는 코드가 변경되지 않을 것이라고 생각하고 작성한 후 변경이 일어날 때, 나중에 일어날 그런 종류의 변경으로부터 보호하는 추상화를 구현하는 것을 추천한다. (= 첫 번째 총알은 그냥 맞고, 그 총에서 쏘는 다른 총알에 대해서는 확실히 보호한다고 표현함)

첫 번째 총알을 맞기로 결정했다면, 우리가 개발 과정에서 너무 멀어지기 전에 어떤 종류의 변경이 일어날 것인지 최대한 빨리 맞는것이 좋다. 아래와 같은 방법으로!

• 테스트를 먼저 작성한다. = 테스트가 가능한 변경은 나중에 우리를 놀라게 하지 않는다.
• 아주 짧은 주기로 개발한다. 일 단위로!
• 빨리, 그리고 자주 릴리즈한다. 가능한 한 빠르게 사용자에게 그것을 보여준다. 

 

---

Reference

• Robert C. Martin - <Clean Software(Agile Software Development)>

책에 나오는 예제 코드는 제외
그냥 내가 기억하고 싶은 내용 위주로 정리