Pattern - 패턴에서 무엇을 기대할 수 있는가?
이책의 디자인 패턴을 알면 기존 시스템을 이해하기가 더욱 쉬워집니다. 대부분의 큰 객체지향 시스템은 이 디자인 패턴을 사용합니다. 객체지향 프로그래밍을 배우는 사람들은 종종 그들이 이해하는 시스템이 상속을 이용하기 때문에 제어의 흐름을 파악하기 힘들다고 불평합니다. 이것은 시스템의 디자인 패턴을 이해하지 못하기 때문입니다.
또한 사용자를 더 훌륭한 설계자로 만들어 줄 수 있습니다. 패턴은 주어진 문제에 대한 일반적인 해결책을 제공합니다. 사용자가 오랫동안 객체 지향 시스템 개발에 참여했다면 이미 나름대로 디자인 패턴을 갖고 있을 것입니다.
객체지향 설계 방법은 훌륭한 설계를 지원하고, 초보 설계자에게 설계를 잘하는 방법을 가르치며, 설계가 개발되어 가는 과정을 표준화 합니다. 설계 방법은 일반적으로 다양한 특징을 표현하는 표현 방법과 각 표현 기법을 언제 어떻게 사용해야 하는 가에 대한 규칙을 정의합니다. 설계 방법은 설계에서 일어나는 문제, 즉 그 설계를 어떻게 해결하고 평가하는 가를 설명합니다. 그러나 이 방법들이 전문 설계자들의 경험을 다 포함할 수는 없습니다.
재사용 가능한 소프트웨어를 개발할 때 나타나는 문제 중 하나는 소프트웨어를 재구성하거나 리팩토링 해야 한다는 것입니다. 디자인 패턴은 설계를 어떻게 재구성할지를 결정하는 데 도움을 줘서 사용자가 나중에 해야 할 리팩토링의 양을 줄일 수 있습니다.
객체지향 소프트웨어의 생명주기에는 여러 가지 단계가 있습니다. 브라이언 푸트는 이 단계를 프로토타이핑, 확장 그리고 통합 단계로 설명합니다.
일단 소프트웨어가 성숙시에 이르고 서비스가 부여되면, 이 소프트웨어의 진화는 두 개의 상충되는 필요에 의해서 통제됩니다.
- 소프트웨어는 더 많은 요구 조건을 만족시켜야 하고,
- 소프트웨어는 더욱더 재사용 가능해야 합니다.
일반적으로 새로운 요구조건은 새로운 클래스 계층을 추가할 것입니다. 소프트웨어는 확장 단계다. 결국, 소프트웨어는 유연성이 없어지고 여기저기 문제가 많이 발생하여 더는 변경을 수용할 수 없게 됩니다. 클래스 계층은 더는 어떤 문제 도메인과도 일치 하지 않는 이상한 모습으로 변했을 것입니다. 클래스 계층은 문제 도메인에 속한 클래스들이기보다는 관련 없는 연산이나 인스턴스 변수들의 클래스로 정의되어 있을 것입니다. 계속 진화하려면, 소프트웨어는 리팩토링이라는 절차를 통해 재구성해야 합니다. 보통 프레임워크는 이 절차를 통해 진화합니다. 리팩토링은 클래스를 특별한 목적에 필요한 구성요소와 일반적 구성요소로 나누고, 연산을 클래스 계통에서 슈퍼클래스로 이동하거나 서브클래스로 이동하며, 클래스의 인터페이스로 합리화합니다. 이 합변 단계에서는 종종 기존 객체들을 분해하기도 하고, 상속 대신 객체 합성을 사용할 수도 있고, 새로운 객체들을 만들기도 합니다. 객체 합성을 사용함에 따라 블랙 박스 재사용 방법이 화이트박스 재사용 방법을 대체 합니다. 더 만은 요구 조건을 만족시키려는 계속적인 요청은 확장과 합병 - 새로운 요구 조건이 만족된 확장과 소프트웨어가 더욱 일반적인 합병 - 단계를 반복함으로써 객체지향 소프트웨어를 더욱 일반적인 것으로 만듭니다.
좀 느슨한 방법으로 패턴을 쭉 늘어놓음으로써 빌딩을 만들 수 있습니다. 이렇게 빌딩을 만드는 것은 패턴을 조합하는 것입니다. 이것을 어렵지도 심오하지도 않습니다. 물리적으로 동일한 공간에서 많은 패턴을 겹치는 방식으로 패턴을 붙일 수도 있습니다. 빌딩에서는 매우 많은 것들이 들어차 있습니다. 빌딩은 작은 공간 속에 많은 의미를 갖고 있습니다. 그리고 이러한 ‘들어참’을 통해서 빌딩은 점점 심오해집니다.