README.md

1장. 디자인 패턴 소개와 전략 패턴

디자인 원칙 (객체지향 원칙)

1. 애플리케이션에서 달라지는 부분을 찾아내고, 달라지지 않는 부분과 분리(캡슐화)한다.

• 코드에 새로운 요구 사항이 있을 때마다 바뀌는 부분이 있다면 분리해야 한다.
• 시스템의 유연성을 향상시킨다.

2. 구현보다는 인터페이스에 맞춰서 프로그래밍한다.

• 인터페이스에 맞춰서 프로그래밍 = 상위 형식(supertype)에 맞춰서 프로그래밍
• 매서드를 하위 클래스에서 직접 구현하기보다 상위 형식의 인스턴스를 만들고, 매서드 형식에 맞춰서 프로그래밍한다.
• 여기서 상위 형식의 인스턴스를 만드는 과정(예를 들어 new Dog())을 추상화하고 실행시에 대입하는 것이 바람직하다.

3. 상속보다는 구성(composition)을 활용한다.

• 유연성을 크게 향상시킬 수 있다.
• (React에서도 같은 이유?)

디자인 패턴 사용법

• 이미 서로 알고 있는 패턴을 통해 커뮤니케이션 속도를 크게 높일 수 있다.
• 패턴을 사용하여 디자인 수준에 초점을 맞출 수 있다.
• 디자인 패턴이 클래스와 객체를 구성해서 어떤 문제를 해결하는 방법을 제공하면, 개발자는 특정 애플리케이션에 맞게 디자인을 적용하는 역할을 한다.
• 디자인 패턴은 프레임워크나 라이브러리보다 높은 단계의 개념이다.
• 객체지향 시스템 구축 방법을 모아서 만든 것이 디자인 패턴이다.
• 디자인 패턴을 찾을 수 없다면 객체지향 원칙(추상화, 캡슐화, 다형성 등)을 생각하는 것이 도움이 된다.

전략 패턴 (Strategy Pattern)

• 알고리즘군을 정의하고 캡슐화해서 각각의 알고리즘군을 수정해서 쓸 수 있게 해준다.
• 전략 패턴을 사용하여 클라이언트로부터 알고리즘을 분리해서 독립적으로 변경할 수 있다.

2장. 옵저버 패턴

용어 정리

• 옵저버 패턴(oberver pattern): 한 객체의 상태가 바뀌면 그 객체에 의존하는 다른 객체에게 연락이 가고 자동으로 내용이 갱신되는 방식으로, 일대다 의존성을 정의한다.
• 주제(subject): 상태(데이터)를 저장하고 있는 객체
• 옵저버(observer): 상태 변화가 일어날 때마다 데이터를 받는 객체
• 느슨한 결합(loose coupling): 객체들이 상호작용할 수는 있지만 서로를 잘 모르는 관계.
• publish-scribe pattern: 서로 다른 유형의 메세지에 관심을 가질 수 있고, 역할을 더 세세하게 분리할 수 있는 패턴으로, 미들웨어 시스템에서 많이 쓰인다.

푸시 방식과 풀 방식

• 푸시 방식: 주제가 옵저버에게 상태를 알리는 방식

public void update(float temperature, float humidity, float pressure) {
 this.temperature = temperature;
 this.humidity = humidity;
 display();
}

• 풀 방식: 주제에서 옵저버가 상태를 끌어오는 방식

public void update() {
 this.temperature = weatherData.getTemperature();
 this.humidity = weatherData.getHumidity();
 display();
}

3장. 데코레이터 패턴

• 데코레이터 패턴을 사용해서 서브클래스를 만드는 것보다 유연하게 기능을 확장할 수 있다.
• 기본 구성 요소와는 다른 데코레이터 등을 인스턴스 변수에 저장하여 연결한다.
• 필요한 코드와 클래스가 많아진다는 단점은 팩토리 및 빌더 패턴으로 보완한다.

4장. 팩토리 패턴

5장. 싱글턴 패턴

• 하나의 인스턴스만 만들고, 그 인스턴스로의 전역 접근을 제공할 때 사용한다.
• 정적 인스턴스를 생성하고, getInstance와 이 인스턴스에 같이 접근할 수 있는 메서드를 제공한다. getInstance에서는 호출할 때까지 인스턴스 생성을 미룰 수 있다. (lazy initialization)
• 멀티스레딩 환경에서 여러 스레드가 getInstance에 동시에 접근하면, 인스턴스의 유일성을 보장할 수 없다. (자바 기준) 세 가지 방법이 있다.
  • (병목을 감당할 수 있다면) 동기적으로 실행되게 한다.
  • 인스턴스를 정적으로 초기화하고 lazy initialization을 하지 않는다.
  • DCL(Double-Checked Locking)을 사용한다.
• Python 버전...? 참고

6장. 커맨드 패턴

• 작업을 객체로 캡슐화하고, 작업을 요청하는 객체와 작업을 처리하는 객체를 분리 (예: 리모컨에서 작업을 요청하면 각 기기에서 작업을 처리)
  • Command(예: 작업) : 공통 작업 인터페이스, client들은 반드시 이를 구현 (예: execute, undo)
  • Client(예: 기기들) : 원하는 행동들로 구성된 커맨드 객체를 생성하여 invoker에 넘기기 (+ 나중에 invoker에 의해 실행됨)
  • Invoker(예: 리모컨) : 커맨드를 등록하는 메서드를 제공, 커맨드의 실행을 유발

7장. 어댑터 패턴과 퍼사드 패턴

• 어댑터 패턴
  • 인터페이스가 호환되지 않아 사용될 수 없었던 클래스를 사용할 수 있도록 어댑터 클래스를 도입
  • 기존 코드를 크게 수정하지 않을 수 있다는 것이 가장 큰 장점
• 퍼사드 패턴
  • 서브시스템에 있는 일련의 인터페이스를 통합 인터페이스로 묶어 주는 패턴
  • 클라이언트는 하나의 통합 인터페이스에 연결되며, 통합 인터페이스는 (클라이언트 대신) 모든 서브시스템을 관리
  • 최소 지식 원칙(데메테르의 법칙): 객체 자체, 메소드에 매개변수로 전달된 객체, 메소드를 생성하거나 인스턴스를 만든 객체, 객체에 속하는 구성 요소의 메소드만 호출하라는 가이드라인

8장. 템플릿 메소드 패턴

• 슈퍼클래스의 템플릿 메소드는 여러 메소드를 사용하여 알고리즘을 작성한다.
• 템플릿 메소드는 슈퍼클래스에서 직접 정의한 메소드, 추상 메소드로서 서브클래스에서 구현하는 메소드, 훅으로 이루어진다.
• 훅(hook)은 기본적으로 아무일도 일어나지 않는 빈 메소드지만, 서브클래스에서 오버라이드한다면 템플릿 메소드에서 호출하는 메소드 외의 동작을 구현할 수 있다.
• 이론적으로는 클래스 상속으로 구현해야 하지만, (오리 정렬과 같이) 클래스 상속이 아닌 관계에서도 템플릿 메소드 패턴의 아이디어를 활용할 수 있다.
• 할리우드 원칙 : 고수준 -> 저수준 구성 요소 방향으로만 호출하여 고수준 구성 요소와 저수준 구성 요소 사이에 순환 의존성이 생기지 않게 한다.

9장. 반복자 패턴과 컴포지트 패턴

• 반복자(iterator) 패턴: 여러 컬렉션(collection)이 같은 인터페이스로 순회할 수 있게 함 - Python은 언어를 만들 때 이 패턴을 썼다고 볼수도 있는건가?
• 컴포지트(composite) 패턴: 트리 구조에서 composite와 leaf는 같은 component 인터페이스를 구현
• 컴포지트 패턴은 투명성을 위해 단일 역할 원칙을 어느 정도 희생한다고 볼 수도 있다. 그런데 어디까지 '하나'의 역할이라고 할 수 있을까?

10장. 상태 패턴

• 상태(state) 클래스를 정의하고 모든 상태는 이 클래스를 구현

11장. 프록시 패턴

12장. 복합 패턴

13장. 실전 디자인 패턴

14장. 기타 패턴