GOF의 디자인 패턴 1장, 서론을 정리해봅니다.

머리말

• 디자인 패턴은 이름만 언급해도 복잡한 설계에 대한 의도를 표현하는 효과를 가진다.
• 이 책의 공헌
  • 복잡한 시스템 설계에서 패턴의 역할을 보여줌
  • 숙련된 개발자가 각각의 어플리케이션에 적용할 수 있는 패턴을 제공함
• 한번 읽고 완벽하게 이해할 것이라 생각하지 마라.

디자인 패턴이란?

설계 시 마주쳤던 경험들을 기반으로 귀납적 추론한 결과물들.

• 소프트웨어 설계 패턴은 건축에서 많은 영향을 받았다. "크리스토퍼 알렉산더"는 그 중 한명이다.
• "각 디자인 패턴은 기존 환경내에서 반복적으로 일어나는 문제를 설명 후 해법의 핵심을 알려줍니다. 두번 다시 같은 방법으로 하지 말고 100만번 재사용할 수 있도록 말이죠"
• 객체 지향 설계에서도 이는 적용된다.

패턴이 가지는 네가지 요소

1. 패턴 이름
   • 한두 단어로 설계 문제와 해법을 서술한다.
   • 가장 어려운 부분.
2. 문제
   • 언제 패턴을 사용하는가?
   • 그 배경은 무엇인가?
   • 기존에 어떤 구조를 가지고 있었는가?
3. 해법
   • 설계를 구성하는 요소
   • 요소들 간의 관계
   • 책임
   • 협력관계
   • 구체적인 설계나 구현을 설명하지는 않음
   • 결국 패턴은 template이기 때문
4. 결과
   • 결과와 장단점
   • 이 부분이 가장 중요.
   • 이를 기반으로 엔지니어는 적용 여부를 판단하기 때문
   • 비용: 시간, 언어의 다름, 공간, 효율, 재사용성 등

SmallTalk MVC를 사용한 디자인 패턴

• Model, View, Controller를 하나의 객체에서 처리하게되면 위와 같은 것을 처리하기 어려워진다.
  • 이렇게 View를 떼어내는 설계 방법은 더 일반적인 문제에도 적용이 가능하다.
  • Model에서 일어난 변경을 다른 객체 들에 반영하도록 하여 변경이 일어난 객체는 반영이 필요한 객체들에 대해 알필요가 없게 분리한 것,
  • 이런 설계를 일반화하면 Observer Pattern이 된다.
• View에서는 각각의 View를 중첩시킬 수 있다.
  • 즉, 제어판이라는 View요소는 Button이라는 View의 Composition으로 구성된다.
  • 그러면서도 복합 View를 단일 View로 처리할 수도 있다. (제어판 View는 View를 상속)
  • 이런 설계를 일반화하면 Composite Pattern이 된다.
• Controller를 변경하면, User Input에 대해 기존과 다른 방식으로 동작하도록 할 수 있다.
  • 즉, 사용자 입력에 대해 다른 대응 전략을 사용하고 싶을 경우 Controller를 변경하면 된다는 것이다.
  • 이는 Strategy Pattern의 한 예이다.

디자인 패턴 기술하기

디자인 패턴에 대해 설명하는 방법을 말한다.

• 패턴이름과 분류
• 의도
• 다른 이름
• 동기
  • 해당 패턴 안에서 객체 구조가 어떻게 문제를 해결할 수 있을까?
  • 시나리오를 기반으로 도와줌
• 활용성
  • 어떤 상황에 적용가능할까?
  • 잘못된 설계의 예는 무엇일까?
  • 어떻게 파악할 수 있을까?
• 구조
  • Class Diagram
  • Sequence Diagram
• 참여자
  • 해당 구조에 참여하는 객체를 설명함
• 협력 방법
  • 참여자들이 어떻게 협력하는지 정의함
• 결과
  • 이 패턴을 이용한 결과는 무엇인가?
  • 장단점은 무엇인가?
  • 시스템에서는 어떤 부분을 독립적으로 다양화할 수 있을까?
• 구현
  • 주의해야 할 부분은 무엇인가?
  • 언어에 따라 있는 특이사항은 있는가?
• 예제 코드
  • C++, SmallTalk
• 사용예
  • 실제 시스템에서 찾아볼 수 있는 패턴들의 예시
• 관련 패턴
  • 이 패턴과 관련된 패턴은 무엇인가?
  • 그들과의 차이점은 무엇인가?

디자인 패턴 카탈로그

이 책에서는 23개의 패턴를 소개한다.

1. Abstract Factory

• 구체적 클래스를 지정하지 않음
• 관련성이 있는 객체들의 집합을 생성
• 혹은 독립적인 객체들의 집합을 생성
• 이러한 인터페이스를 제공

2. Adapter

• 클래스의 인터페이스를 사용자가 기대하는 다른 인터페이스로 변환
• 호환성이 없는 인터페이스 때문에 함께 동작이 불가한 클래스를 묶어줌

3. Bridge

• 구현부에서 추상층을 분리하여, 독립적으로 변형할 수 있게 하는 패턴

4. Builder

• 복합 객체의 생성 과정과 표현 방법을 분리
• 생성 객체가 분리되어 동일한 생성 절차를 가짐에도 다른 결과를 만들 수 있게 해줌

5. Chain of Responsibility

• 요청을 받는 객체를 연쇄적으로 묶어, 실제 요청을 처리할 객체를 만날 때까지 전달하는 패턴
• iOS의 Responder chanin

6. Command

• 요청 자체를 캡슐화하여 여러 기능을 실행할 수 있는 재사용성이 높은 클래스를 만드는 패턴

7. Composite

• 객체들의 관계를 트리 구조로 구성하여 부분-전체를 표현함
• 사용자가 단일 객체, 복합 객체를 모두 동일하게 다룰 수 있음

8. Decorator

• 주어진 상황 및 용도에 따라 특정 객체에 책임을 덧붙이는 패턴
• 기능 확장이 필요할 때 서브클래싱 대신 사용할 수 있는 유연한 대안이 될 수 있음

9. Facade

• 서브시스템에 있는 인터페이스 집합에 대해 하나의 통합된 인터페이스를 제공하는 패턴
• 서브시스템을 좀더 사용하기 편하게 만드는 상위 수준의 인터페이스를 제공

10. Factory Method

• 객체 생성 인터페이스는 미리 정의
• 다만, 인스턴스를 만들 클래스의 결정은 서브클래스에서 정하는 패턴

11. Flyweight

• 크기가 작은 객체가 여러개 있을 때, 공유를 통해 효율적으로 지원하는 패턴
• 텍스트 입력기

12. Interpreter

• 주어진 언어에 대해, 그 언어의 문법을 위한 표현 수단을 정의
• 그리고 그 표현 수단을 사용하여 해당 언어로 작성된 문자를 해석하는 해석기를 정의하는 패턴

13. Iterator

• 내부 표현부를 노출하지 않고, 어떤 객체 집한에 속한 원소를 순차적으로 접근할 수 있는 방법을 제공

14. Mediator

• 한 집합에 속한 객체들의 상호작용을 캡슐화
• 서로를 참조하지 안혿록 함으로서 결합도를 줄일 수 있다.

15. Memento

• 특정 객체의 내부 상태를 잡아내고 실체화함
• 후에 해당 객체가 내부 상태를 기반으로 되돌아올 수 있도록 하는 패턴

16. Observer

• 객체 사이 일대다 관계를 정의함
• 특정 객체의 상태가 변경될 때, 묶인 객체들이 변화를 통지받고 자동으로 갱신되게 하는 패턴

17. Prototype

• 생성할 객체의 종류를 명세하는데 원형이 되는 예시물을 이용
• 그리고 이 원형을 복사하여 새로운 객체를 생성하는 패턴

18. Proxy

• 특정 객체로 접근하는 것을 통제하기 위해 객체의 대리자, placeholder를 제공하는 패턴

19. Singleton

• 특정 클래스의 인스턴스를 오직 하나임을 보장
• 전역적인 접촉점을 제공하는 패턴

20. State

• 객체의 내부 상태에 따라 스스로 행동을 변경할 수 있게끔 허가하는 패턴
• 이렇게 하면 객체가 자신의 클래스를 바꾸는 것처럼 보임

21. Strategy

• 동일 계열의 알고리즘군을 정의하고, 알고리즘을 캡슐화함
• 그리고 이것들이 상호교환가능하도록 만들어 사용자에 상관없이 독립적으로 알고리즘을 변경할 수 있도록 함

22. Template Method

• 알고리즘의 뼈대만 정의함
• 각 단계에서 수행할 구체적 처리는 서브클래스 쪽으로 미루는 패턴
• 즉, 구조는 두되, 알고리즘 처리를 서브클래스에서 재정의

23. Visitor

• 객체 구조를 이루는 원소에 대해 수행할 연산을 표현하는 패턴
• 연산을 적용할 원소의 클래스를 변경하지 않고도 새로운 연산을 정의할 수 있음

Reference

• GoF의 디자인 패턴 - 재사용성을 지닌 객체지향 소프트웨어의 핵심요소
• 방문자 패턴 - Visitor pattern