디자인 패턴의 종류

** 이 블로그에서 작성하는 디자인 패턴의 포스팅은 GoF의 디자인패턴 서적을 참고하여 기술하고 있습니다.

---

GoF 디자인패턴

• GoF는 'Gang of Four'의 약자로 에리히 감마(Erich Gamma), 리처드 헬름(Richard Helm), 랄프 존슨(Ralph Johnson, 존 블리시디스(John VLissides) GoF 디자인패턴의 공동 저자 4인을 지칭하는 단어이다.
• 23가지의 디자인 패턴을 정의하고, 각 패턴을 생성(Creational), 구조(Structural), 행위(Behavioral) 3가지로 조직화 했다.

---

** 아래의 패턴은 추후 각 패턴에 대한 블로깅이 작성되면, 링크를 걸어둘 예정입니다.

 

Abstract Factory Pattern (추상 팩토리 패턴)

• 구체적인 클래스를 지정하지 않고 관련성 있는 객체들의 집합을 생성하거나 서로 독립적인 객체들의 집합을 생성할 수 있는 인터페이스를 제공한다.
• 동일한 주제의 다른 팩토리를 묶어 준다.

 

Adapter Pattern (어댑터 패턴)

• 클래스의 인터페이스를 클라이언트가 기대하는 다른 인터페이스로 변환한다. Adapter 패턴은 호환성이 없는 인터페이스 때문에 함께 사용할 수 없는 클래스를 개조하여 함께 작동하도록 해준다.

 

Bridge Pattern (브릿지 패턴)

• 추상화와 구현을 분리해, 각각을 독립적으로 변형할 수 있게 한다.

 

Chain of Responsibility Pattern (책임 연쇄 패턴)

• 요청을 처리할 수 있는 기회를 하나 이상의 객체에 부여해서, 요청하는 객체와 처리하는 객체 사이의 결합도를 없애고자 하는 패턴. 요청을 해결할 객체를 만날 때까지 객체 고리를 따라서 요청을 전달한다.

 

Command Pattern (커맨드 패턴)

• 요청을 객체로 캡슐화함으로써 서로 다른 요청으로 클라이언트를 파라미터화 하고, 요청을 저장하거나 기록을 남겨, 오퍼레이션의 취소도 가능하게 한다.
• 요청을 각자 구현하는 것보다, 하나의 추상 클래스에 method를 하나 만들고, 각 명령이 들어오면 그에 맞는 서브 클래스가 선택되어 실행하게 한다.

 

Composite Pattern (합성 패턴)

• 부분-전체 계층을 나타내기 위해 복합 객체를 트리 구조로 만든다. Composite 패턴은 클라이언트가 단일 객체와 복합 객체 모두를 동일하게 다루도록 한다.

 

Decorator Pattern (데코레이터 패턴)

• 객체에 동적으로 책임을 추가할 수 있게 한다. Decorator Pattern 패턴은 기능의 유연한 확장을 위해 상속 대신 사용할 수 있는 방법이다.

 

Facade Pattern (파사드 패턴)

• 서브시스템에 있는 잇는 인터페이스 집합에 대해서 하나의 통합된 인터페이스를 제공한다. Facade 패턴은 서브시스템을 좀 더 편리하게 사용하기 위해 높은 수준의 인터페이스를 정의한다.
• 서브시스템(또는 대량의 코드)에 접근할 수 있는 인터페이스를 정의하여 제공한다.

 

Factory Method Pattern (팩토리 메서드 패턴)

• 객체를 생성하는 인터페이스를 정의하지만, 인스턴스를 만든 클래스의 결정은 서브클래스가 한다. Factory Method 패턴에서는 클래스의 인스턴스를 만드는 시점을 서브클래스로 미룬다.

 

Flyweight Pattern (플라이웨이트 패턴)

• 작은 크기의 객체들이 여러 개 있는 경우, 객체를 효과적으로 사용하는 방법으로 객체를 공유하게 한다.
• 다수의 비슷한 객체를 생성하고 관리하는 비용을 절감할 수 있다.

 

Interpreter Pattern (해석자 패턴)

• 언어에 따라서 문법에 대한 표현을 정의한다. 한 언어의 문장을 해석하기 위해 정의한 표현에 기반하여 Interpreter를 정의한다.

 

Iterator Pattern (반복자 패턴)

• 내부 표현 방법을 노출하지 않고 복합 객체의 원소를 순차적으로 접근할 수 있는 방법을 제공한다.

 

Mediator Pattern

• 객체들 간의 상호작용을 객체로 캡슐화한다. Mediator 패턴은 객체들간의 참조 관계를 객체에서 분리함으로써 상호작용만을 독립적으로 다양하게 확대할 수 있다.

 

Memento Pattern

• 캡슐화를 위배하지 않고 객체 내부 상태를 객체화하여, 나중에 객체가 이 상태로 복구가 가능하도록 한다.

 

Observer Pattern

• 객체 사이에 1:N의 종속성을 정의하고, 한 객체의 상태가 변하면 종속된 다른 객체에 통보되고 자동으로 수정이 일어나게 한다.

 

Prototype Pattern

• 프로토타입의 인스턴스를 이용해서 생성할 객체의 종류를 명세하고 이 프로토타입을 복사해서 새로운 객체를 생성한다.

 

Proxy Pattern

• 다른 객체로의 접근을 통제하기 위해서 다른 객체의 대리자 또는 다른 객체로의 정보 보유자를 제공한다.

 

Singleton Pattern

• 클래스의 인스턴스는 오직 하나임을 보장하며 이 인스턴스에 접근할 수 있는 방법을 제공한다.

 

State Pattern

• 객체의 내부 상태에 따라 행위를 변경할 수 있게 한다. 이렇게 하면 객체는 마치 클래스를 바꾸는 것처럼 보인다.

 

Strategy Pattern

• 알고리즘군이 존재할 경우 각각의 알고리즘을 별도의 클래스로 캡슐화하고 이들을 상호 교환 가능한 것으로 정의한다. Strategy 패턴은 클라이언트에 영향을 주지 않고 독립적으로 알고리즘을 다양하게 변경할 수 있게 한다.

 

Template Method Pattern

• 오퍼레이션에는 알고리즘의 처리 과정만을 정의하고 각 단계에서 수행할 구체적 처리는 서브클래스에 정의한다. Template Method 패턴은 알고리즘의 처리 과정은 변경하지 않고 알고리즘 각 단계의 처리를 서브클래스에서 재정의 할 수 있게 한다.

 

Visitor Pattern

• 객체 구조의 요소들에 수행할 오퍼레이션을 표현한 패턴이다. Visitor 패턴은 오퍼레이션이 처리할 요소의 클래스를 변경하지 않고도 새로운 오퍼레이션을 정의할 수 있게 한다.

 

정리하다 보면서 느끼게 된 점은, '어..? 이거 아니야?' 하는 것들이 있었다. 자주 사용하는 개발언어에서 이미 해당 패턴을 적용하여 우리가 사용하기 쉽도록 제공한 것들도 있었다. (e.g. Iterator Patter을 활용한 foreach 등의 반복문 명령어 구문)

사실 이런 Deep한 부분까지 공부하는 것에 대한 거부감이랄까.. Too much하다는 생각이 컸었는데, 개발을 계속 하다보니 알아두면 반드시 도움이 될 내용인 것 같다는 느낌적인 느낌이 오기도 한다.

 

무슨 이야기인지 감도 안잡히는 패턴들도 있지만.. 차근차근 자세히 다뤄보도록 하자.

다음 포스팅에서는 이러한 패턴을 생성, 구조, 행동의 형태의 카테고리로 조직화하는 내용에 관해 작성할 예정이다.

 

 

GoF의 디자인 패턴, 위키피디아 디자인패턴 참고