디자인 패턴을 이용하는 방법 (4)

 

변화에 대비한 설계

지난 포스팅에서는 디자인 패턴의 재사용성에 대해 알아보았다. 디자인 패턴을 통해 재사용을 최대화 하기 위해서는 새로운 요구사항과 기존의 요구 사항에 발생한 변경을 예측하여 시스템 설계가 진화할 수 있도록 해야한다.

변화에 잘 대응하기 위한 소프트웨어를 설계하기 위해서는 미래에 일어날 변화를 어떻게 수용할 것인가를 미리 고려해야 한다. 변화를 수용하지 못하는 설계는 앞으로 재설계를 필요로 하게 된다. 이런 변경들은 클래스의 재설계와 재구현, 수정과 그에 따른 새로운 테스팅을 유발하는데, 재설계의 영향은 프로젝트의 여러 부분에 영향을 끼칠 수 있고, 예측하지 못한 변경은 많은 비용을 발생한다.

** 극 공감이다. 처음의 설계가 잘못되어 설계를 수정한다는 것이 어떻게 보면 프로그램의 근간을 들어내서 수정하는 것이기 때문에 전체 수정이 불가피 한 경우도 더러 봤다..

 

디자인 패턴은 시스템이 앞으로 어떤 구체적인 원인에 의해 변경이 필요할 것이라는 것을 미리 확신함으로써 이런 위험을 줄이는데 일조한다. 재설계를 하게 만드는 일반적인 이유는 무엇이며, 이를 처리하는 디자인 패턴은 어떤 것이 있는지 알아보자.

• 특정 클래스로 부터 객체를 생성
  객체를 생성할 때, 클래스 이름을 명시하면 어떤 특정 인터페이스가 아닌 어떤 특정 구현에 종속된다. 이런 종속은 앞으로의 변화를 수용하지 못한다. 이를 방지하기 위해선 객체를 직접 생성하는 것을 지양해야 한다.
  디자인패턴: Abstract Factory, Factory Method, Prototype
• 특정 오페레이션으로의 종속성
  특정 오퍼레이션을 사용하면, 요청을 만족하는 한 가지 방법에만 메이게 된다. 요청의 처리 방법을 직접 코딩하는 방식을 피하면, 컴파일/런타임 시점 모두를 만족시키며, 요청 처리 방법을 쉽게 변경할 수 있다.
  디자인패턴: Chain of Responsibility, Command
• 하드웨어와 스프트웨어 플랫폼에 종속적
  기존에 존재하는 시스템이나 어플리케이션 프로그래밍은 소프트웨어 및 하드웨어 플랫폼마다 모두 다르다. 특정 플랫폼에 종속된 소프트웨어는 다른 플랫폼에 이식하기 어렵기 때문에 이러한 플랫폼 종속성을 제거하는 것은 중요한 일이다.
  디자인패턴: Abstract Factory, Bridge
• 객체의 표현이나 구현의 종속성
  클라이언트가 객체의 표현 방법, 저장 방법, 구현 방법, 존재의 위치에 대한 모든 방법을 알고 있다면 객체를 변경할 때 클라이언트도 함께 변경해야 한다. 이런 정보를 클라이언트에 감춤으로써 변화의 파급을 방지할 수 있다.
  디자인패턴: Abstract Factory, Bridge, Memento, Proxy
• 알고리즘의 종속성
  알고리즘 자체를 확장, 최적화 ,다른 것으로 대체하는 경우가 있는데, 알고리즘에 종속된 객체라면 알고리즘이 변할 때마다 객체도 변경되어야 한다. 그러므로 변경이 가능한 알고리즘은 분리해 내는 것이 맞다.
  디자인패턴: Builder, Iterator, Strategy, Template Method, Visitor
• 높은 결합도
  높은 결합도를 갖는 클래스들은 독립적으로 재사용하기 어렵다. 높은 결합도를 갖게 되면 하나의 커다란 시스템이 되어 버린다. 이렇게 되면 클래스 하나를 수정하기 위해서 전체를 이해해야 하고 다른 많은 클래스도 변경해야 한다. 
  약한 결합도는 클래스 자체의 재사용을 가능하게 하고 시스템의 이해와 수정, 확장이 용이해서 이식성을 증대시킨다.
  디자인패턴: Abstract Factory, Bridge, Chain of Responsibility, Command, Facade, Mediator, Observer
• 서브클래싱을 통한 기능성의 확장
  서브클래싱에 의해 객체를 재정의하는 것은 쉬운 일이 아니다. 새로운 클래스마다 매번 반드시 해야 하는 초기화, 소멸 등에 대한 구현 부담을 늘 지게 된다. 서브클래스를 정의하려면, 최상위 클래스부터 자신의 직속 부모 클래스까지 모든 것을 이해하고 있어야 한다. 
  일반적으로 객체 합성과 위임은 행위의 상속보다 훨씬 유연한 방법이다. 기존의 객체들을 새로운 방식으로 조합함으로써 새로운 서브클래스를 정의하지 않고도 애플리케이션에 새로운 기능성을 추가할 수 있다. 한편, 객체 합성을 많이 사용한 시스템은 이해하기가 어려워 진다. 그래서 대부분 많은 디자인 패턴에서는 서브클래스를 일단 정의하고, 다른 인스턴스와 새로 정의한 클래스의 인스턴스를 합성해서 기능성을 재정의 하는 방법을 도입하고 있다.
  디자인패턴: Bridge, Chain of Responsibility, Decorator, Observer, Strategy
• 클래스 변경이 편하지 못한 점
  가끔 클래스를 변경하는 것이 그렇게 단순한 작업이 아닐 때가 많다. 소스 코드가 필요한데 없다고 가정해 보자. 또한 어떤 변경을 하면 기존의 서브클래스의 다수를 수정해야 한다고 가정해보자. 디자인 패턴은 이런 환경에서 클래스를 수정하는 방법을 제시한다.
  디자인패턴: Adapter, Decorator, Visitor

위의 예제들은 디자인 패턴이 소프트웨어 구축에 어떤 유연성을 줄 수 잇는지 보여준다. 이런 유연성이 얼마나 중요한지의 여부는 개발하는 시스템마다 달라질 수 있을 것이다.

 

GoF의 디자인패턴 참고