Design Pattern 간략 정리

1. Facade Pattern

  1) 의도 : 기존에 존재하고 있던 시스템 혹은 Method를 이용하는 방법을 단순화시킴(Encapsulation)
  2) 문제점 : 복잡한 시스템의 오직 부분만을 이용해야 한다. 또는 특별한 방법으로 그 시스템과 상호작용해야 한다.
  3) 해결책 : 기존에 존재하고 있던 시스템을 이용하려고 하는 이들을 위해 새로운 인터페이스 제시
  4) 결과 : 서브시스템의 이용을 단순화 시킬 수 있으나, 이 새로운 패턴이 모든 기능을 다 처리하지 않기에 일부기능은 사용치 못할 수도 있다.
  5) 구현 : 필요한 인터페이스를 갖는 새로운 클래스(or 클래스 그룹) 정의(상속, 혹은 포함의 방법으로)
               새로운 클래스는 기존에 존재하던 시스템을 이용하게끔 한다.

2. Adapter Pattern

  1) 의도 : 통제 범위 외에 있던 기존에 존재하고 있던 객체를 특별한 인터페이스를 이용하여 통제 시킴
  2) 문제점 : 시스템은 올바른 데이터와 Method로 수행되지만, 잘못된(호환되지 않는) Interface를 가지고 있다.
  3) 해결책 : 원하는 인터페이스를 가진 Wrapper 제공
  4) 결과 : 이미 존재하는 객체들이 각자의 인터페이스의 제약을 받지 않고 새로운 클래스 구조에 맞출 수 있다.
  5) 구현 : 또 다른 클래스에 기존에 존재하고 있던 클래스를 포함시키고 연결시킨다.

3. Bridge Pattern

  1) 의도 : 구현을 이용하는 객체의 집합으로부터 구현의 집합을 분리한다.
  2) 문제점 : 추상 클래스의 파생 클래스는 클래스의 숫자가 폭발적으로 증가치 않도록 하면서 다양한 구현을 허용해야 한다.
  3) 해결책 : 이용하고자 하는 모든 구현에 대한 인터페이스를 정의하고, 이 구현을 이용하는 추상클래스의 파생 클래스를 갖는다.
  4) 결과 : 구현을 이용하는 객체로부터 그 구현을 분리하는 것은 확장성을 높여준다
              (클라이언트 객체는 세부 구현 사항에 대해 알지 못한다)
  5) 구현 : 완전추상 클래스를 통하여 구현의 형태만을 정의하고, 그를 상속받은 구현 클래스를 실제로 두어 구현 클래스의 초기화를 담당케 한다.

4. Abstract Factory Pattern

  1) 의도 : 특정 클라이언트(or cases)를 위한 객체 집합이나 군을 갖기 희망한다.
  2) 문제점 : 관련된 객체 군은 인스턴스화 되어야 한다.
  3) 해결책 : 객체 군의 생성 시기를 조정하고, 생성된 객체를 이용하는 클라이언트 객체 밖에서 인스턴스를 수행할 수 있도록 규칙을 제공한다.
  4) 결과 : 객체를 이용하는 방법에 대한 로직으로부터 어떤 객체를 이용할 것인가 하는 규칙을 분리한다.
  5) 구현 : 상황에 따라 어떤 객체가 만들어지는지 명시한 추상 클래스를 정의하고, 객체들의 각 군을 위해 구체적인 클래스를 구현한다.

5. Strategy Pattern

  1) 의도 : 서로 다른 알고리즘을 이들이 발생하는 전후 관계에 따라 이용할 수 있게 한다.
  2) 문제점 : 클라이언트의 요청 혹은 데이터의 행동에 맞게 적용되어야 한다. 변경되지 않는 규칙을 적소에 가지고 있다면 이 패턴은 필요가 없다.
  3) 해결책 : 알고리즘의 구현과 선택 부분을 분리한다.
  4) 결과 : Strategy 패턴은 알고리즘의 한 군(family)을 정의한다.
               switch 혹은 조건문이 제거될 수 있다.
               모든 알고리즘은 동일한 인터페이스를 가져야 한다.
  5) 구현 : 알고리즘을 호출하는 방법을 명시하는 추상 Method를 갖는 추상 class를 갖고, 각각의 파생 클래스는 필요에 따라 알고리즘을 구현한다.

6. Decorator Pattern

  1) 의도 : 객체에 추가적인 기능을 동적으로 첨부한다.
  2) 문제점 : 이용하기를 원하는 객체는 요구하는 기본적인 기능을 수행할 수 있으나, 그 기능 전후에 발생하는 몇 가지 추가적인 기능을 객체에 추가하길 원한다.
  3) 해결책 : 서브클래스로 기능을 분류하는 것에 의지하지 않고, 객체의 기능 확장을 이용한다.
  4) 결과 : 추가되는 기능은 작은 객체들 안에 존재한다.
  5) 구현 : 본래의 클래스가 있을 때, 그 클래스를 하나의 부분적인 컴포넌트 클래스로 보고, 다른 컴포넌트(가 있다고 가정하에)들을 포함시킬 수 있는(새로운 기능을 모두 나타내는) 컨테이너 클래스를 생성한다.

7. Singleton Pattern

  1) 의도 : 오직 하나의 객체만을 갖고 싶지만 이 객체의 인스턴스화를 제어하는 전역 객체는 없어야 한다.
  2) 문제점 : 몇몇 다른 클라이언트 객체가 동일한 객체를 참조해야 하고, 개발자는 클라이언트가 참조하는 객체가 단 하나만 존재하는 것을 보증해야만 한다.
  3) 해결법 : 하나의 인스턴스만이 존재한다는 것을 보장한다.
  4) 결과 : 클라이언트는 singleton의 인스턴스가 존재하는지 신경쓸 필요가 없다. 이는 singleton 안에서 제어된다.
  5) 구현 : 전역 멤버 변수를 활용하여(초기값 NULL), 객체 호출시 멤버 변수가 NULL일 경우에만 해당 객체를 인스턴스화시킨다.
               오로지 static 생성자 메커니즘을 통해서만 인스턴스화 시킬 수 있도록 생성자의 접근 가능성을 protected / private로 설정한다.

8. Double-Checked Locking Pattern

  1) 의도 : Multi-thread 상에서 유일한 인스턴스 보장
  2) 문제점 : 하나의 thread만을 사용할 경우, 전역변수 영역은 하나이지만 Multi-thread 사용시 각각의 thread는 각각의 전역변수 영역을 가지고 있다(Singleton으로 해결할 수 없음)
  3) 해결법 : 모든 thread 상에서 전역변수는 같은 영역을 가리키고 있음을 보장해야 한다.
  4) 결과 : thread에 상관없이 유일 객체임을 보장받을 수 있으나 동기화 문제 때문에 Deadlock에 걸릴 위험이 있음
  5) 구현 : singleton 패턴에 동기화 코드를 삽입시킨다.

9. Observer Pattern

  1) 의도 : 한 객체의 상태가 변경되면 이 객체의 의존적인 모든 객체는 통지를 받게 되고, 자동으로 수정되기 위해 객체들 간의 일대 다 의존관계를 정의한다.
  2) 문제점 : 이벤트가 발생했다는 것을, 변화하는 객체들의 목록에 통지해야 한다.
  3) 해결책 : Observer는 이벤트를 탐지하는 책임을 중앙 객체(Subject)에게 전가한다.
  4) 결과 : Subjeet는 만약 몇몇 Observer가 이벤트의 일부분에 대해서만 알고자 하여도 필요로 하지 않는 이벤트들에 대해서도 말을 한다.
  5) 구현 : 이벤트 발생을 알고 싶어하는 Observer class가 있다고 가정할 때, 이들을 관리하는 Subject class를 만들어 Attach / Detach 함수를 통해 이벤트 발생시 Subject class가 Broadcasting할 수 있게끔 한다.
              일부 클래스를 모두 통합하기 위해서는 Adapter Pattern이 일부 적용되기도 한다.