본문 바로가기
OOP/SOLID 원칙

OCP-개방 폐쇄원칙

by Box 2022. 1. 19.
728x90

개방 폐쇄원칙

개방 폐쇄 원칙은 "확장에는 열려 있어야 하고, 변경에는 닫혀 있어야 한다."를 의미한다.
조금 더 쉽게 풀어 쓰자면, "기능을 변경하거나 확장할 수 있으면서 그 기능을 사용하는 코드는 수정하지 않는다."를 뜻한다.

개방 폐쇄 원칙을 지키는 방법

1. 개방 폐쇄 원칙을 구현하는 첫 번째 방법은 추상화를 이용하는 것이다.

 

메모리에서 byte를 읽어 오는 기능을 추가해야 할 경우, ByteSource 인터페이스를 상속받은 MemoryByteSource 클래스를 구현함으로써 기능 추가가 가능하다.

그리고 새로운 기능이 추가되었지만, 이 새로운 기능을 사용할 FlowController 클래스의 코드는 변경되지 않는다.

즉, 기능을 확장 하면서도 기능을 사용하는 기존 코드는 변경되지 않는 것이다.

위 그림과 같은 구조가 개방 폐쇄 원칙을 구현할 수 있는 이유는

확장되는 부분(즉, 변화되는 부분)을 추상화해서 표현했기 때문이다.

변화되는 부분은 byte 데이터를 읽어 오는 기능이었다.

FlowController 클래스 입장에서 변화되는 부분을 ByteSource 인터페이스로 추상화함으로써 byte 읽기 기능을 고정시킬 수 있게 되었다.

따라서, byte 읽기 기능을 고정시켰기 때문에, 새로운 byte 읽기 기능 구현을 추가하면서도 FlowController 클래스를 수정하지 않아도 된 것이다.

 

2. 개방 폐쇄 원칙을 구현하는 또 다른 방법은 상속을 이용.

상속은 상위 클래스의 기능을 그대로 사용하면서 하위 클래스에서 일부 구현을 오버라이딩 할 수 있는 방법을 제공한다.

 

예를 들어, 클라이언트의 요청이 왔을 때 데이터를 HTTP 응답 프로토콜에 맞춰 데이터를 전송해 주는 객체가 있다고 하자.
 

 

class ResponseSender {
  private Data data;
  ResponseSender(Data data) {
    this.data = data;

  }

  Data getData() {
    return data;

  }

  send() {
    sendHeader();
    sendBody();

  }

  sendHeader() {
    // 헤더 데이터 전송

  }

  sendBody() {
    // 텍스트로 데이터 전송

  }

}

 

 

ResponseSender 클래스의 send() 메서드는 헤더와 뭄체 내용을 전송하기 위해 sendHeader() 메서드와 sendBody() 메서드를 차례대로 호출하며, 이 두 메서드는 알맞게 HTTP 응답 데이터를 생성한다.

sendHeader() 메서드와 sendBody() 메서드는 protected 공개 범위를 갖고 있기 때문에, 하위 클래스에서 이 두메서드를 오버라이딩 할 수 있다.

만약 압축해서 데이터를 전송하는 기능을 추가하고 싶다면, ResponseSender 클래스를 상속받은 클래스에서 sendHeader() 메서드와 sendBody() 메서드를 오버라이딩하면 된다.

class ZippedResponseSender extends ResponseSender {
   ZippedResponseSender(Data data) {
    super(data);

  }

  @Override
   sendBody() {
    // 데이터 압축 처리

  }

}
 
ZippedResponseSender 클래스는 기존 기능에 압축 기능을 추가해 주는데,
이 기능을 추가하기 위해 ResponseSender 클래스 코드는 바뀌지 않았다.
즉, ResponseSender 클래스는 확장에는 열려 있으면서 변경에는 닫혀 있는 것이다.
ResponseSender 클래스 예제는 템플릿 패턴을 사용한 것이다. 템플릿 메서드 패턴은 상위 클래스에서 실행할 기본 코드를 만들고 하위 클래스에서 필요에 따라 확장해 나가는 패턴이다.

개방 폐쇄 원칙이 깨질 때의 주요 증상

추상화다형성을 이용해서 개방 폐쇄 원칙을 구현하기 때문에,
추상화와 다형성이 제대로 지켜지지 않은 코드는 개방 폐쇄 원칙을 어기게 된다.
개방 폐쇄 원칙을 어기는 코드의 전형적인 특징은 다음과 같다.

1. 다운캐스팅을 한다.
2. 비슷한 if-else 블록이 존재한다.
- 참조
https://koseungbin.gitbook.io/wiki/books/undefined/part-2.-di/solid/open-closed-principle

개방 폐쇄 원칙(Open - Closed Principle) - Developer Log

메모리에서 byte를 읽어 오는 기능을 추가해야 할 경우, ByteSource 인터페이스를 상속받은 MemoryByteSource 클래스를 구현함으로써 기능 추가가 가능하다. 그리고 새로운 기능이 추가되었지만, 이 새로

koseungbin.gitbook.io

정리

개방 폐쇄 원칙은 유연함에 관련된 원칙입니다.
변화하는 부분을 추상화함으로써 기존 코드를 수정하지 않고도, 확장을 할 수 있게 만들어 줍니다.
따라서, 우리는 개발을 하다가 코드에 대한 변화 요구가 발생하면,
변화와 관련된 구현을 추상화해서 개방 폐쇄 원칙에 맞게 수정할 수 있는지 확인해 보는 습관을 길러야 합니다.

'OOP > SOLID 원칙' 카테고리의 다른 글

DIP- 의존역전 원칙  (0) 2022.01.21
ISP- 인터페이스 분리 원칙  (0) 2022.01.21
LSP 리스코프 치환 원칙  (0) 2022.01.19
SRP-단일 책임원칙  (0) 2022.01.09