00. [Design Pattern] 디자인 패턴이란?

 

객체지향 언어를 사용하는 프로그래머들은 언제나 객체지향 프로그래밍, 객체지향적 소프트웨어를 설계해야 한다. 그렇다면 객체지향 프로그래밍이란 무엇일까? 객체지향 프로그래밍이란 프로그램을 하나의 덩어리가 아닌 수많은 객체(Object)로 나누고, 이러한 객체들 간의 상호작용을 통해 로직을 구성하는 프로그래밍 기법이다. 객체들을 모아 하나의 기능을 가진 컴포넌트(Component)를 구성하고, 컴포넌트 간의 상호작용을 통해 더 큰 시스템을 만들고, 더 나아가 컴포넌트를 재사용함으로써 더 효율적이고 유연한 프로그램을 만들 수 있는 게 큰 장점이다.

하지만 안타깝게도 우린 객체지향 언어를 배웠지만 유연하고, 근사하며, 재사용 가능한 객체지향 소프트웨어를 설계할 줄 모른다. 다형성도 알고, 캡슐화도 알고, 추상화도 알지만 이를 어디에(What), 언제(When), 어떻게(How) 사용해야 좋은지 알기엔 개발 경험이 부족한 노릇이다. 

디자인 패턴과 객체지향 프로그래밍

디자인 패턴(Design Pattern)은 이러한 고민을 했던 수많은 선배들의 지식과 노력이 모여 만들어진 솔루션이라고 할 수 있다. 디자인 패턴은 개발을 하면서 발생할 수 있는 문제(What)들을 유형별(When)로 나눠서 해결책(How)을 제시한다. 문제들은 대부분 비슷한 이유로 발생하기 때문에 수학 공식처럼 문제와 해결법만 외우면 대부분 해결할 수 있다. 디자인 패턴을 안다면 해결책을 찾는 시간을 단축하고, 나아가 더 유연하고 재사용이 가능한 프로그램 설계가 가능해진다.

디자인 패턴의 장점

• 좋은 설계나 아키텍처 재사용성 증가
• 이미 만들어진 시스템의 유지보수나 문서화 개선
• 클래스의 명세를 정확하게 파악 가능
• 객체 간의 상호작용 및 설계의 의도를 명확하게 정의할 수 있음

디자인 패턴과 협업

디자인 패턴은 프로그래머들 사이에서 공유되는 패턴이다. 프로그래머들이 의사소통 할 때 양쪽 모두 디자인 패턴을 알고 있다면 간단한 단어로 복잡한 의사소통을 대체하는 것이 가능해진다. 의사소통을 간단한 단어로 대체하는 것이 가능해지면, 프로그래밍 구조 관점에서 프로그램에 대해 논의하는 것이 수월해진다. 더욱 높은 레벨에서 의사소통을 함으로써 더욱 쉽게 이해할 수 있게 된다.

디자읜 패턴의 종류

• 생성(Creational) - 인스턴스를 만드는 절차를 추상화하는 패턴
  
  • 추상 팩토리(Abstract Factory) - 구체적인 클래스를 지정하지 않고 관련성을 갖는 객체들의 집합을 생성하거나 서로 독립적인 객체들의 집합을 생성할 수 있는 인터페이스를 제공한다.
  • 팩토리 메서드(Factory Mothod) - 객체를 생성하는 인터페이스를 미리 저으이하되, 인스턴스를 만들 클래스의 결정은 서브클래스 쪽에서 내리는 패턴. 클래스의 인스턴스를 만드는 시점을 서브클래스로 미룬다.
  • 빌더(Builder) - 복합 객체의 생성 과정과 표현 방법을 분리하여 동일한 생성 절차에서 서로 다른 표현 결과를 만들 수 있게 하는 패턴.
  • 프로토타입(Prototype) - 생성할 객체의 종류를 명세하는 데에 원형이 되는 예시물을 이용하고, 그 원형ㅇ을 복사함으로써 새로운 객체를 생성하는 패턴.
  • 싱글톤(Singleton) - 어떤 클래스의 인스턴스는 오직 하나임을 보장하며, 이 인스턴스에 접근할 수 있는 전역적인 접촉점을 제공하는 패턴.
• 구조(Structural) - 더 큰 구조를 형성하기 위해 어떻게 클래스와 객체를 합성하는가와 관련된 패턴
  • 적응자(Adapter) - 클래스의 인터페이스를 사용자가 기대하는 다른 인터페이스로 변환하는 패턴. 호환성이 없는 인터페이스 때문에 함께 동작할 수 없는 클래스들이 함께 작동하도록 만들어준다.
  • 브릿지(Bridge) - 구현부에서 추상층을 분리하여 각자 독립적으로 변형할 수 있게 하는 패턴
  • 복합체(Composite) - 객체들의 관계를 트리 구조로 구성하여 부분-전체 계층을 표현하는 패턴. 사용자가 단일 객체와 복합 객체 모두 동일하게 다루도록 한다.
  • 장식자(Decorator) - 주어진 상황 및 용도에 따라 어떤 객쳉 책임을 덧붙이는 패턴. 기능 확장이 필요할 때 서브클래싱 대신 쓸 수 있는 유연한 대한이 된다.
  • 퍼사드(Facade) - 서비슷템에 있는 인터페이스 집합에 대해 하나의 통합된 인터페이스를 제공하는 패턴. 서브시스템을 좀더 사용하기 편하게 만드는 상위 수준의 인터페이스를 정의한다.
  • 플라이급(Flyweight) - 크기가 작은 객체가 여러 개 있을 때, 공유를 통해 이들을 효율적으로 지원하는 패턴.
  • 프록시(Proxy) - 어떤 다른 객체로 접근하는 것을 통제하기 위해서 그 객체의 대리자 또는 자리채움자를 제공하는 패턴.
• 행동(Behavioral) - 어떤 처리의 책임의 할당과 알고리즘의 정의를 어느 객체에 하는게 좋을지 정의하는 것과 관련된 패턴
  • 감시자(Observer) -  객체들 사이에 일대 다의 의존 관계를 정의하여, 어떤 객체의 상태가 변할 시 그 객체의 의존성을 가진 다른 객체들을 그 변화를 통지받고 자동으로 갱신될 수 있게 만드는 패턴.
  • 상태(State) - 객체의 내부 상태에 따라 스스로 행동을 변경할 수 있게끔 허가하는 패턴.
  • 전략(Strategy) - 동일 계열의 알고리즘군을 정의하고, 각각의 알고리즘을 캡슐화하며, 이들을 상호 교환이 가능하도록 만드는 패턴. 알고리즘을 사용하는 사용자와 상관없이 독립적으로 알고리즘을 다양하게 변경할 수 있다.
  • 책임 연쇄(Chain of Responsibility) - 요청을 처리할 수 있는 기회를 하나 이상의 객체에게 부여하여 요청을 보내는 객체와 그 요청을 받는 객체 사이의 결합을 피하는 패턴.
  • 명령(Command) - 요청을 객체의 형태로 캡슐화하여 서로 요청이 다른 사용자의 매개변수화, 요청 저장 또는 로깅, 연산의 취소를 지원하게 만드는 패턴.
  • 해석자(InterPreter) - 주어진 언어에 대해 그 언어의 문법을 위한 표현 수단을 정의하고, 동시에 그 표현 수단을 사용하여 해당 언어로 작성된 문장을 해석하는 해석기를 정의하는 패턴.
  • 반복자(Iterator) - 내부 표현부를 노충하지 않고 어떤 객체 집합에 속한 원소들을 순차적으로 접근할 수 있는 방법을 제공하는 패턴.
  • 중재자(Mediator) - 한 집합에 속해있는 객체들의 상호작용을 캡슐화하는 객체를 정의하는 패턴. 객체들은 서로를 직접 참조하지 않음으로써 소결합 상태로르 유지하며, 개발자가 객체들의 상호작용을 독립적으로 다양화시킬 수 있게 만든다.
  • 메멘토(Memeto) - 캡슐화를 위배하지 안흥ㄴ 채로 어떤 객체의 내부 상태를 잡아내고 실체화시켜, 이후 해당 객체가 그 상태로 되동아올 수 있도록 하는 패턴.
  • 템플릿 메서드(Templet Method) - 객체의 연산에는 알고리즘의 뼈대만을 정의하고, 각 단계에서 수행할 구체적 처리는 서브클래스 쪽으로 미루는 패턴.
  • 방문자(Visitor) - 객체 구조를 이루는 원소에 대해 수행할 연산을 표현하는 패턴. 연산을 적용할 원소의 클래스를 변경하지 않고도 새로운 연산을 정의할 수 있게 한다.

---

참고자료

GoF의 디자인 패턴 - 예스24