Open Closed Principle : OCP

Open Closed Principle

훌륭한 어플리케이션 디자인과 코드 작성 부분은 개발이 진행이 되는 도중과 어플리케이션의 단계에서 자주 변경되는 것을 염두에 둬야 합니다. 보통은 많은 변경들은 다양한 기능들이 어플리케이션에 추가 될 때와 관련되어 집니다. 현재 코드가 이미 단위 테스트되고 현재 코드에서 불필요한 방식으로 현존하는 기능들에 영향을 미칠 수 있는 것을 수정할 때 까지 이러한 변화들은  최소화 되어야만 합니다.

Open Close Principle 코드의 디자인과 작성은 현존하는 코드에서 최소한의 변화로 새로운 기능이 추가 되어져야하는 방법이 되어야한다고 말합니다. 디자인은 현존하는 코드를 수정하지 않는 것과 같이 새 클래스들이나, 새로운 기능을 허가하는 방법으로 되어져야 합니다.

Intent

함수, 클래스, 모듈과 같은 소프트웨어 요소들은 확장을 위해서 열려져야 합니다. 하지만 수정을 위해서는 닫혀져야 합니다

Example

아래의 예는 OCP를 위반한 예입니다. 이 예제는 다른 형태의 객체를 그리는 것을 조작하는 그래픽 에디터를 구현했습니다. GraphicEditor 클래스가 추가되어야 하는 모든 새로운 형태를 위해서 수정되어져야만 한다는 것부터 OCP를 따르지 않았다는 것을 알 수 있습니다. 다음과 같은 단점이 있습니다.

// Open-Close Principle - Bad example

class GraphicEditor {

   public void drawShape(Shape s) {

       if (s.m_type==1)

           drawRectangle(s);

       else if (s.m_type==2)

           drawCircle(s);

   }

   public void drawCircle(Circle r) {....}

   public void drawRectangle(Rectangle r) {....}

}

class Shape {

   int m_type;

}

class Rectangle extends Shape {

   Rectangle() {

       super.m_type=1;

   }

}

class Circle extends Shape {

   Circle() {

       super.m_type=2;

   }

}

- 각 새로운 형태는 수정된 GraphicEditor 클래스의 단위테스트가 추가됩니다.

- 추가된 개발자가 GraphicEditor 클래스의 로직을 이해하는 시간과 새로운 형태가 추가되면서 새로운 타입이 추가될 때의 시간은 엄청날 것입니다.

- 추가된 새로운 형태는 비록 새로운 형태의 처리가 완벽하더라도 원치 않는 방법으로 존재하는 기능들에 영향을 미치게 될 것입니다.

더 극적인 효과를 위해서, 형태가 단 한명의 개발자에 의해서 구현되는 동안 GraphicEditor는 다수의 개발자들에 의해서 변화되고 작성되는 많은 기능들이 담겨 있는 큰 클래스라고 상상해봅시다. 이런 경우에는 GraphicEditor 클래스의 변화 없이 새로운 형태를 추가를 허가할 수 있는 큰 향상이 됩니다.

아래는 OCP를 추가한 예제입니다. 구체적인 형태 객체를 구현하는 동안에 객체를 그리기 위해서 GraphicEditor내부에 추상화된 코드를 사용합니다. GraphicEditor 는 새로운 형태의 클래스가 추가 되었을때 변화되지 않기 때문에 위와 같은 디자인을 사용하는 문제점은 OCP를 사용하는 것으로 피할 수 있습니다.

[#M_ more.. | less.. |

// Open-Close Principle - Good example

class GraphicEditor {

   public void drawShape(Shape s) {

       s.draw();

   }

}

class Shape {

   abstract void draw();

}

class Rectangle extends Shape {

   public void draw() {

       // draw the rectangle

   }

}

_M#]

단위테스트가 필요 없습니다.

- GraphicEditor 클래스로부터 코드를 이해할 필요가 없습니다.

- drawing 코드를 구체화된 형태의 클래스로 옮기기 까지는 새 기능이 추가될 때에 구 기능에 영향을 미치는 위험을 줄여줍니다.

Conclusion

OCP와 같은 모든 원리들은 그저 원리일 뿐입니다. 유연한 디자인을 만드는 것은 추가적인 시간과 노력을 필요로 합니다. 또 코드의 적합성을 증진시키는 새로운 추상 단계를 소개합니다. 그래서 이 원리는 빈번하게 바뀌게 되는 영역에서 적용 되어야 합니다.