개방-폐쇄 원칙

개방-폐쇄 원칙(Open-Closed Principle, OCP)은 소프트웨어 모듈이 확장에는 열려 있고 수정에는 닫혀 있어야 한다는, 곧 기존 코드를 고치지 않고 새 코드를 더하는 것만으로 동작을 바꾸거나 늘릴 수 있게 설계해야 한다는 객체지향 설계 원칙으로, SOLID 의 O 에 해당한다.

개요

버트런드 마이어(Bertrand Meyer)가 1988년 『Object-Oriented Software Construction』에서 처음 정식화했다. 마이어는 좋은 모듈 분해는 모듈을 열린 상태(기능과 자료를 더할 수 있음)이면서 동시에 닫힌 상태(안정된 인터페이스로 다른 모듈이 믿고 쓸 수 있음)로 만들어야 한다고 했다. 로버트 C. 마틴(Robert C. Martin)은 이를 "시스템을 수정하지 않고도 시스템의 동작을 확장할 수 있어야 한다"로 다시 풀고, 새 기능을 오직 새 코드를 써서 더할 수 있으면 옛 코드는 다시 컴파일하거나 배포할 필요도 없다고 설명했다. 플러그인 구조가 이 원칙의 대표적인 구현이다.

구현 방법

변하는 부분을 추상화(인터페이스, 추상 클래스) 뒤에 숨기고, 변하지 않는 정책 코드는 그 추상화에만 의존하게 한다. 새 요구가 오면 추상화를 구현한 새 클래스를 더하고 기존 클래스는 그대로 둔다.

• 전략 패턴 - 알고리즘을 객체로 바꿔 끼운다. 새 전략을 더해도 Context 는 고치지 않는다
• 템플릿 메서드, 옵서버 패턴 - 골격이나 통보 대상을 고정하고 확장 지점만 연다
• 조건문을 다형성으로 바꾸기 - 형식마다 갈라지는 switch 문을 하위 클래스로 바꿔, 새 형식이 생겨도 switch 를 고치지 않게 한다
• 의존성 주입 - 객체가 쓸 협력 객체를 밖에서 넣어 준다. 의존관계 역전 원칙과 함께 쓰인다

테스트 용이성과의 관계

단위 테스트에서 테스트 대상 클래스가 데이터베이스, 네트워크, 시계 같은 외부 환경을 직접 만들어 쓰면, 테스트하려고 그 클래스 코드를 고치거나 실제 환경을 갖춰야 한다. OCP 를 따라 외부 환경을 인터페이스 뒤로 빼 두면 테스트 대상 클래스를 변경하지 않고 그 자리에 가짜 객체(스텁, 목)를 넣어 테스트가 통제할 수 있는 환경으로 바꿀 수 있다.

interface Clock { LocalTime now(); }

class Alarm {
    private final Clock clock;            // 구체 시계가 아니라 추상화에 의존
    Alarm(Clock clock) { this.clock = clock; }
    boolean ring() { return clock.now().getHour() == 7; }
}

// 테스트: Alarm 은 고치지 않고 시각을 고정한 가짜 시계를 넣는다
Alarm a = new Alarm(() -> LocalTime.of(7, 0));
assert a.ring();

Alarm 이 안에서 시스템 시계를 직접 불렀다면 오전 7시 동작을 시험하려고 코드를 고치거나 7시까지 기다려야 한다. 테스트용 환경으로 바꿔 끼우는 것도 '수정 없이 확장'하는 한 경우이다.

SOLID 의 다른 원칙과 구별하기

원칙	요점	OCP 와의 차이
단일 책임 원칙(SRP)	클래스는 바뀌어야 할 이유가 하나뿐이어야 한다	책임을 나누는 기준이다. 수정 없이 확장하는 구조를 말하지 않는다
개방-폐쇄 원칙(OCP)	수정에는 닫고 확장에는 연다	-
리스코프 치환 원칙(LSP)	하위 타입은 상위 타입 자리에 넣어도 기대대로 동작해야 한다	상속이 행위까지 맞는지 보는 기준이다
인터페이스 분리 원칙(ISP)	쓰지 않는 메서드에 의존하지 않게 인터페이스를 쪼갠다	인터페이스의 크기를 다룬다
의존관계 역전 원칙(DIP)	상위·하위 모듈 모두 추상화에 의존한다	의존 방향을 다룬다. OCP 를 이루는 수단으로 함께 쓰인다

"테스트 대상 클래스를 변경하지 않고 환경을 바꿀 수 있어야 한다"는 요구는 '변경하지 않고(폐쇄) 바꿀 수 있게(개방)'라는 OCP 의 문장 그대로이다. DIP 는 그것을 가능하게 하는 의존 방향의 규칙이고, SRP 와 LSP 는 이 요구를 직접 말하지 않는다.

같이 보기

• 객체지향 설계 원칙
• 의존관계 역전 원칙
• 리스코프 치환 원칙
• 전략 패턴
• 클린 아키텍처