OCP (Open Closed Principle)

Open and Closed

"Open for extension But, Closed for modification"

확장에 대해서는 열려있고 변경에 대해서는 닫혀있어야 한다.

여기서의 "Open for extendsion" 이란 새로운 타입을 추가함으로써 새로운 기능을 추가할 수 있다는 것을 의미한다.

그 다음 "Closed for modification" 이란 이러한 확장이 일어날 때 상위 레벨이 영향을 받지 말아야 한다는 것을 의미한다.

이러한 방식을 잘 준수한다면, 어떤 모듈의 행위를 소스코드의 변경 없이 쉽게 변경할 수 있다.

OCP Example

OCP를 지키기 위해서는 추상화와 역전(Inversion)이 필요하다.

• insert abstract interface between copy and device

• cause the inverted dependencies

interface Reader {
    Integer getChar();
}

interface Writer {
    void putChar(Integer c);
}

public class Copy {

    public void copy(Reader reader, Writer writer) {
        Integer c;
        
        while ((c = reader.getChar() != null)) {
            writer.putChar(c);
        }
    }
}

class TestReader implements Reader {
    @Override
    public Integer getChar() {
        // do something...
    }
}

class TestWriter implements Writer {
    @Override
    public void putChar(Integer c) {
        // do something...
    }
}

Reader, Writer가 추가된다고 Copy 클래스에 변경이 일어날까?

디바이스(Reader, Writer)가 추가되면 해당 디아비스를 담당하는 클래스를 추가하지만, copy 로직의 수정은 일어나지 않는다.

OCP가 가능한 것인가?

OCP를 준수하면 변경을 완벽하게 제거할 수 있는가?

• 이론적으로는 가능하다.

• 하지만, 실용적이지 않다.

2가지 문제점

• main partition

  • 메인 파트의 경우 if-else가 없을 순 없다. 스프링과 같이 DI 컨테이너가 존재하는 경우 대신해주니까 배제하게 된다.

• Crystal ball problem (마법의 수정구슬 문제)

  • 나도 모르는 것이 많기 때문에 미리 인터페이스를 다 준비하는 방식은 사실상 불가능하다.

  • 확장에 필요한 모든 것을 인터페이스화 한다면 굉장히 복잡해질 것이다.

A Smelly Design

GitHub - msbaek/expense: Clean Coders Episode 10 OCP Expense ExampleGitHub

  public void printReport(ReportPrinter printer) {
    int total = 0;
    int mealExpenses = 0;

    printer.print("Expenses " + getDate() + "\n");

    for (Expense expense : expenses) {
      if (expense.type == BREAKFAST || expense.type == DINNER)
        mealExpenses += expense.amount;

      String name = "TILT";
      switch (expense.type) {
        case DINNER: name = "Dinner"; break;
        case BREAKFAST: name = "Breakfast"; break;
        case CAR_RENTAL: name = "Car Rental"; break;
      }
      printer.print(String.format("%s\t%s\t$%.02f\n",
        (  (expense.type == DINNER && expense.amount > 5000)
        || (expense.type == BREAKFAST && expense.amount > 1000)) ? "X" : " ",
        name, expense.amount / 100.0));

      total += expense.amount;
    }

    printer.print(String.format("\nMeal expenses $%.02f",mealExpenses / 100.0 ));
    printer.print(String.format("\nTotal $%.02f", total / 100.0));
  }

비용(Expense) 목록을 바탕으로 리포트를 출력하는 메서드

• 각 비용의 종류와 금액을 출력하며, 식사 비용(BREAKFAST, DINNER)은 별도로 집계

• 리포트 하단에 식사 비용 총액과 전체 비용 총액을 출력

위 코드의 문제점은 무엇일까?

1. SRP 위반

• 메서드 내부에서 비즈니스 규칙, 메시지 생성, 포맷팅과 같은 하나의 책임만을 가지고 있는 상태가 아님

1. OCP 위반

• 비즈니스 규칙을 확장하려면 수정이 필요한 상태

• 또한, 메시지 생성 및 포맷팅을 확장하려면 수정이 필요한 상태

Rigidity / Fragility / Immobility Problem

위 코드에서의 문제점들에 대해서 분석해보자.

경직성(Rigidity)

시스템에서 하나의 변경이 모든 변경을 유발할 경우 경직성이 높다고 한다.

• 식사 타입(meal type)에 LUNCH, SNACK 과 같은 타입을 추가한다는 요구사항에 대응하려면 어떻게 해야하는가?

Even though the design change is small, the impact is huge. So the system resist change. It's rigid.

설계 변경은 사소해 보이지만, 그 영향은 매우 큽니다. 그래서 시스템은 변화에 저항합니다. 이것이 경직된 상태입니다.

취약성(Fragility)

시스템에서 하나의 변경으로 인해 전체적으로 취약한 부분이 많이 생기는 것을 말한다.

• switch문이나 조건문으로 나눌 경우, 변경을 가할 때 누락되는 것이 없는지, 잘못 변경한 것은 없는지 어떻게 체크하지?

즉, Fan-out Problem을 가지고 있으며 Fragility하다. 모든 Design smell 중 Fragility가 가장 먼저 제거해야할 대상이다.

부동성(Immobility)

시스템의 재사용성이 떨어지고, 코드의 변경이 어려운 것을 말한다.

• 기업용 솔루션에 맞춰진 시스템을 대부분의 기능이 필요하지 않는 작은 비즈니스 영역으로 분리할 수 있을까?

The Lie

고객이 전혀 고려하지 않은 새로운 기능을 요구하면 대책이 없다. 만일 미리 얘기해줬다면 추상화를 적용했을 것이다.

⇒ 그렇다면, OCP를 준수하기 위해서는 미래에 어떤 일, 어떤 확장이 필요한지 미리 다 알아야 한다는 말인가?

우리가 아무리 잘 준비하고 예측해도, 고객은 준비하지 못한 것에 대한 기능 추가/변경을 요구한다.

⇒ 이 것을 해결하기 위해서 마법의 수정 구슬(Crystal ball)이 필요한거 아닌가?

이것이 OCP에 대한 비밀이다. 우리가 미래를 예측할 수 있을 때만 해당 기능을 보호할 수 있다.

Two Solutions

우리는 미래를 예측하지 못하는데 어떻게 OCP를 지킬 수 있을까?

Big Design Up Front(BDUF)

과도한 설계를 하는 것이다. 코드를 한 줄을 작성하기 전, 설계를 굉장히 많이 하는 방법이다.

해결 방법

• 고객과 문제 영역을 고찰하며, 요구사항을 예측하여 도메인 모델을 만든다.

• OCP가 가능하도록 도메인 모델에 추상화를 적용한다.

• 모든 것에 대한 청사진을 얻을 때 까지 반복한다.

문제

• 필요치 않는 추상화로 도배된 매우 크고, 무겁고 복잡한 설계가 되어버릴 수 있다.

• 추상화는 유용하고 강력한 만큼 비용도 크다.

막상 고객은 우리가 추상화 해논 것에 대한 변경을 요청하지 않는다. 즉, 효율적인 방식이 아니다!

Agile Design - 은유법

실용적이고 반응을 하는 방법으로 가장 좋은 예시법은 은유법(메타포)이다.

은유법

• 최대한 빨리 고객의 요구사항을 끌어낼 수 있는 가장 단순한 일을 한다.

• 그렇다면 고객은 그 결과물에 대해 요구사항 변경을 시작한다.

• 따라서, 어떤 변경이 요구되는지 알게된다.

[시나리오]

- 병사들이 적군의 사격에 포위됐다.
- 총탄이 난발하고 있는 가운데 참호에 숨어있다.
- 적을 향해 집중 사격할 수 있으면 전투에서 승리한다.
- 문제는 어디에 적이 있을지 모른다는 것이다.
- 어떤 방향에서 적들이 총을 쏘는지 모른다. 

BDUF 방식으로 접근한다면, 포위망이 좁혀져 더 나쁜 상황이 되어버린다.

이러한 상황에서 상사가 XXX 일병에게 일어나라고 명령한다.
=> 적군이 사격한다. 우리는 총알이 날아온 방향을 알아낸 것이다. (이게 맞나?)

이 내용으로 알 수 있는 것은 변화에 대한 가장 좋은 예측은 변화를 경험하는 것이라는 것이다.

물론 우리는 BDUF와 Agile 두 극단 사이에 살아간다. BDUF는 피해야 하지만 No DUF도 피해야 한다! 시스템에 대해서 사고하고 Decoupled 모델을 사전에 설계하는 것은 매우 가치있는 일이다.

정리 및 핵심

• 우리는 완벽한 미래를 예측할 수 없다. 리팩토링을 통해서 추상화하며 OCP를 준수하도록 하자.

• 너무 깊은 설계가 아닌, 적절한 시스템 모델에 대한 사전 설계를 진행하자.