스트렛지(Strategy)
스트레티지 패턴은 행동/전략 등 동일계열의 알고리즘들을 인터페이스-캡슐화하고,
알고리즘들을 컴포지션(위임 형태로) 가지는 패턴이다.
장점
- 상황에 따라 사용할 알고리즘을 쉽게 바꿀 수 있다.
- 알고리즘 구현부와 사용부가 분리되어 있다.
- 인터페이스로 사용자는 일관성있게 알고리즘을 가져다 쓸 수 있고,
- 각 알고리즘들은 동일한 인터페이스를 가지되, 각각 목적에 따라 구현은 다르게할 수 있다.
단점
- 다 사용하지 않는 정보들을 모든 알고리즘이 떠안아야 한다.
- 각 구체적인 알고리즘들마다 필요한 입력 파라미터가 다 다를 수 있다.
- 하지만 인터페이스로 파라미터가 고정되어 있으므로, 굳이 이 알고리즘에 필요없는 파라미터도 다 받게된다.
- 알고리즘 수 만큼 전체 객체 수가 증가한다.
활용 상황
- 상황에 따라 사용해야할 알고리즘(전략)을 클라이언트가 정해야 할 때.
- 동일 계열의 알고리즘들을 인터페이스로 통일하여 제공해야 할 때.
구조
Template Method
템플릿메쏘드 패턴은 상위 클래스가 뼈대가 되는 로직을 구성하고,
하위 클래스들이 이 로직의 요소들을 각각 구현하는 패턴이다.
장점
로직과 로직요소를 분리하여, 전체 로직은 동일하되 로직 요소를 각각 다르게할 수 있다.
단점
- 추상 클래스와 구현 클래스가 강하게 연결되어 있다.
- 상속 때문에 하향적으로 강해지는 한편, 상위 클래스의 메쏘드를 사용하므로 상향적으로도 강해진다.
- 로직 요소(추상 메쏘드) 가 많아지면 클래스 자체가 복잡해질 수 있다.
활용 상황
- 같은 로직을 가지고 있는 알고리즘들을 큰 뼈대 / 작은 요소로 나누어 관리하기가 쉬울 때.
- 명확한 로직이 있고, 로직에 들어가는 변수들을 잘 컴포넌트화 시킬 수 있는 경우.
구조
옵저버(Observer)
옵저버 패턴은 하나의 관찰대상 - 여러 개의 관찰자 구조가 필요할 때 쓰는 패턴이다.
활용 상황
- 관찰대상 - 관찰자의 구조를 가질 때 쓰면 된다.
- 이벤트 핸들러가 대표적인 옵저버 패턴의 예다.
- 이벤트 핸들러 : Observer
- 이벤트 : Subject
구조
Subject
- 관찰 대상이 되는 객체
- 자신을 관찰하는 옵저버들 리스트를 가지고 관리도 함.
- 옵저버 붙이기(attach), 떼기(detach), 알리기(notfiy) 를 가지고 있어야 함.
Observer
- Subject 를 관찰하는 객체
- Subejct 가 notify 를 호출하면 Observer 의 update 도 호출됨.
- 즉 Observer.update() 에 관찰 대상이 notify 했을 때의 할 일들을 적으면 됨.
상태(State)
상태 패턴은 상태 자체를 객체화함으로써,
상태에 따른 액션도 상태 객체에 내부에 구현하는 패턴이다.
장점
- 상태 종류 증가에 따른 길어지는 조건문을 제거하고, 가독성 좋게 코드를 짤 수 있다.
- 상태 - 행위를 묶기 때문에, 주체(클래스) 자체는 상태에 따른 행동 구현과 분리된다.
단점
- 상태 종류에 따라 클래스가 늘어난다.
- 상태와 행동에 강력한 결합이 생긴다.
활용 상황
- 주체(클래스) 에서 동일 계열의 상태들에 따라 조건문이 많아지는 경우
- 이런 경우가 여러 클래스에서 등장하는 경우
- 즉 이런 조건문 반복 코드가 여기저기서 발견될 때
구조
State
- 상태를 나타내는 추상 클래스.
- ex. class LightState 이런 식으로 상태를 추상화 함.
- 각 상태에 따른 액션(메쏘드) 인터페이스를 정의한다.
- 같은 계열의 상태이므로, 각 상태에 따른 동일한 인터페이스(메쏘드)를 가지고 있다.
- 각 액션은 handle() 로 표현되며 ConcreteState 클래스에서 이를 구현한다.
ConcreteState
- State 를 상속받아 구체적인 상태를 나타내는 클래스
- ex. class ON(LightState), class OFF(LightState) 이런 식으로 구체적인 상태를 표현.
- handle 를 구체적으로 구현한다.
