OCP : The Open Closed Principle

SOFTWARE ENTITIES (CLASSES, MODULES, FUNCTIONS, ETC.)

SHOULD BE OPEN FOR EXTENSION, BUT CLOSED FOR MODIFICATION.

S/W의 요소(클래스, 모듈, function)은 확장에는 열려있고, 

수정에는 닫혀있어야 한다.

This principle has a high-falutin’ definition, but a simple meaning: You should be able to

change the environment surrounding a module without changing the module itself.

이 원리의 핵심은 어떤 특정 기능을 시스템 자체의 모듈을 변화시키지 않고도, 

기능상의 변화를 줄 수 있다는 것이다.

Consider, for example, Figure 6-4. It shows a simple application that deals with

Employee objects through a database facade named EmployeeDB. The facade deals

directly with API of the database. This violates the OCP because a change to the implementation

of the EmployeeDB class can force a rebuild of the Employee class.

The Employee is transitively bound to the database API. Any system that contains the

Employee class must also contain TheDatabase API.

EmployeeDB는 DAO 역할을 하는 class이며, DB의 API를 직접적으로 Access하는데,

이것은 OCP 위반에 해당된다. 왜냐하면 EmployeeDB의 변경이 client, 즉 Employee의 

변화까지 동반하기 때문이다.

결국 coupling으로 인해 기능상 확장성이 떨어지는 구조라 하겠다.

Unit tests are often the places where we want to make controlled changes to the environment.

Consider, for example, how we would test Employee. Employee objects make

changes to the database. In a test environment we don’t want the real database to change.

We also don’t want to create dummy databases just for the purposes of unit testing.

Instead, we’d like to change the environment so that the test catches all the calls that

Employee makes to the database, and verifies that those calls are made correctly.

Employee를 Unit 테스트할 경우 Real DB에 영향을 주는 것은 문제가 될 수 있으며,

Test를 위한 Dummy Object를 생성하는 것도 코드의 수정을 동반하기 때문에 좋지 못하다.

결국 Employee의 호출을 검증할 수 있는 테스트 환경의 제공이 최적의 조건이라 할 수 있다.

We can do this by converting EmployeeDB to an interface as in Figure 6-5. Then we

can create derivatives that either invoke the true database API, or that support our tests.

The interface separates Employee from the database API, and allows us the change the

database environment that surrounds Employee without affecting Employee at all.

이러한 문제는 DAO 자체를 Interface로 변경해서 해결할 수 있다.

테스트용 DB 환경과 Real DB 환경을 유연하게 사용할 수 있다.

Empoyee에 어떠한 영향을 주지 않고 자유롭게 DB 환경을 제어할 수 있다는것 이점.