개방-폐쇄의 원칙 (The Open-Closed Principle; OCP)

소프트웨어 엔티티(클래스,모듈,함수 등)는 확장에 대해서는 개발되어야 하지만, 변경에 대해서는 폐쇄되어야 한다.

이 원칙은 정의는 거창하지만 의미는 간단하다.

• 모듈 자체를 변경하지 않고도 그 모듈을 둘러싼 환견을 바꿀 수 있어야 한다.

가령, 아래와 같은 구조의 경우 EmployeeDB라는 데이터베이스 퍼사드(facade)를 통해 Employee 객체를 다루는 간단한 구조다. EmployeeDB 퍼사드는 데이터베이스 API를 직접 다루고 있다. 이것이 OCP 위반이다.

• 왜냐하면, EmployeeDB 클래스의 구현이 변경되면, Employee 클래스도 다시 빌드해야할지도 모르기 때문이다. Employee는 EmployeeDB를 통해 데이터베이스 API에도 묶인(커플링된) 셈이다.
• 또한 Employee 클래스를 포함하는 시스템은 반드시 TheDatabase API 까지 포함해야한다

단위 테스트를 할때는 환경에 생기는 변화를 제어하고 싶을때, 실제 DB보다는 테스트용 인메모리 DB 등을 사용하고 싶은 경우가 있다.

• 하지만 강결합되거나 실제 구현체를 사용한다면 DB를 변경하기 어렵지만, EmployeeDB를 인터페이스로 사용한다면 구현체를 바꿔서 테스트를 용이 하도록 할수 있다.
• 또한 TheDatabase와의 커플링도 분리되기 때문에, Employee를 손대지 않고도 구현체를 원하는 대로 변경가능하다.

추상화된 인터페이스는 모듈을 둘러싼 환경을 우리 마음대로 바꿀수 있게 해준다. 추상화야 말로 OCP를 지키기 위한 열쇠다.