본문 바로가기

Language/C++ Design Pattern

OCP 원칙

개방-폐쇄 원칙(Open-Close Principle OCP)

(C++ 소프트웨어 디자인 책 정리)


(클래스, 모듈, 함수 등) 소프트웨어 산출물은 확장에는 열려 있지만 수정에는 닫혀 있어야 한다.

 

OCP는 소프트웨어를 확장할 수 있어야 한다고 말한다(확장에 열려 있음). 하지만 확장이 쉬워야 하고, 최선의 경우 새 코드를 추가하는 것만으로 확장 가능해야 한다. 즉, 기존 코드를 수정할 필요가 없어야 한다(수정에 닫혀 있음).

 

위 원칙을 설명하기 앞서 다른 원칙에서 설명을 했던 Document 클래스를 살펴보자.

class Document
{
  public:
  // ...
  virtual ~Document() = default;
  
  virtual void exportToJSON( /*...*/ ) const = 0;
  virtual void seriallize( ByteStream&, /*...*/ ) const = 0;
  
  // ...
  
 };

 

여기서 serialize() 멤버 함수를 구현한다면 어떻게 할까? 한가지 요구 사항은 나중에 바이트를 다른 인스턴스로 다시 변환할 수 있어야 한다는 것이다. 이를 위해 그 바이트가 나타내느 정보를 저장하는 것이 필수다. 따라서 아래와 같이 바이트 정보를 나타내는 열거형이 있다.

enum class DocumentType
{
  pdf,
  word,
  // ... 있을 수 있는 더 많은 문서 유형
};

이 열거형 클래스로 인해 모든 종료의 문서가 결합됐다. 즉 PDF 클랫스는 워드 형식에 관해 알고 있다. 물론 해당 Word클래스는 PDF형식에 관해 알 것이다. 그렇다 이 두 클래스는 구현 상세를 모르지만 여전히 서로 알고 있다.

 

여기서 DocumentType에 새로운 타입으로 xml을 추가한하다고 하면 document 클래스에서 파생한 xml 클래스를 추가하기만 하면 된다. 하지만 불행히도 DocumentType 열거형도 이에 맞게 조정해야 한다. 최악의 경우, 누구나 DocumentType 열거형을 확장할 수 있는 것은 아니므로 다른 이가 코드를 확장하는 것, 즉 새 문서 종류를 추가하는 것을 상당히 제한한다.

즉 pdf와 word는 새 xml 형식을 전혀 몰라야 한다.

 

아래와 같이 관심사를 분리하고 진정으로 함꼐 속한 것을 하나로 묶음으로써 서로 다른 종류의 문서 간 우연한 결합이 사라진다.

 

 

'Language > C++ Design Pattern' 카테고리의 다른 글

Visitor 패턴  (1) 2025.02.02
DIP 원칙  (0) 2025.01.30
LSP 원칙  (0) 2025.01.30
ISP 원칙  (0) 2025.01.29
SRP 원칙  (0) 2025.01.29