미로

방문자 패턴은 객체와 구조를 이루는 원소에 대해 수행할 연산을 표현한다. 연산을 적용할 원소의 클래스를 변경하지 않고도 새로운 연산을 정의할 수있게 한다.

구조

특징

사용 시기

• 객체 구조에 포함된 원소에 대해 구체 방문자 클래스에 따라 달라질 연산을 원소에 대해 수행 할 때
• 각각 특징이 있고 관련되지 않은 많은 연산이 한 객체 구조에 속해 있는 객체들에 대해 수행될 필요가 있으며 연산으로 클래스들을 더럽히고 싶지 않을 때
• 객체 구조를 정의한 클래스는 거의 변하지 않지만 전체 구조에 걸쳐 새로운 연산을 추가하고 싶을 때

장점

• 기존 코드를 수정하지 않고 새로운 코드를 추가할 수 있다. 
• 추가 기능을 한곳에 모을 수 있다.

단점

• 복잡하다
• 새로운 Element 를 추가하거나 제거할 때 모든 Visitor 코드를 수정해야 한다.

전략 패턴은 실행(런타임) 중에 알고리즘 전략을 선택하여 객체 동작을 실시간으로 바뀌도록 할 수 있게 하는 행위 디자인 패턴.

알고리즘 변형이 빈번하게 필요한 경우에 적합한 패턴

구조

전략 알고리즘 객체들(ConcreateStrategy1, ConcreateStrategy2, ConcreateStrategy3)

• 알고리즘, 행위, 동작을 객체로 정의한 구현체

전략 인터페이스(Strategty)

• 모든 전략 구현체에 대한 공용 인터페이스

컨텍스트(Context)

• 알고리즘을 실행해야 할 때마다 해당 알고리즘과 연결된 전략 객체의 메소드를 호출

클라이언트

• 특정 전략 객체를 컨텍스트에 전달 함으로써 전략을 등록하거나 변경하여 전략 알고리즘을 실행한 결과를 누린다.

특징

전략패턴은 SOLID 원칙의 OCP원칙, DIP원칙, 합성(composition), 다형성(polymorphism), 캡슐화(encapsulation) 등 OOP 기술들의 총 집합 버전이라고 보면 된다.

• 동일 계열의 알고리즘군을 정의 - 전략 구현체로 정의
• 각각의 알고리즘을 캡슐화하여 - 인터페이스로 추상화
• 이들을 상호 교환이 가능하도록 만든다. - 합성(composition)으로 구성
• 알고리즘을 사용하는 클라이언트와 상관없이 독립적 - 컨텍스트 객체 수정 없이
• 알고리즘을 다양하게 변경할 수 있게 한다. - 메소드를 통해 전략 객체를 실시간으로 변경함으로써 잔략을 변경

클래스 구성

클래스 흐름

사용 시기

• 전략 알고리즘의 여러 버전 또는 변형이 필요할 때 클래스화를 통해 관리
• 알고리즘 코드가 노출되어서는 안되는 데이터에 엑세스 하거나 데이터를 활용할 때(캡슐화)
• 알고리즘의 동작이 런타임에 실시간으로 교체 되어야 할때
•  

주의점

• 알고리즘이 많아질수록 관리해야할 객체의 수가 늘어난다는 단점
• 만일 어플리케이션 특성이 알고리즘이 많지 않고 자주 변경되지 않는다면, 새로운 클래스와 인터페이스를 만들어 프로그램을 복잡하게 만들 이유가 없다.
• 개발자는 적절한 전략을 선택하기 위해 전략 간의 차이점을 파악하고 있어야 한다.(복잡도가 올라감)

상태패턴은 객체가 특정 상태에 따라 행위를 달리하는 상황에서, 상태를 조건문으로 검사해서 행위를 달리는 것이 아닌, 상태를 객체화 하여 상태가 행동을 할 수 있도록 위임하는 패턴

구조

State 인터페이스

• 상태를 추상화한 고수준 모듈

ConcreteState

• 구체적인 각각의 상태를 클래스로 표현.
• State 역할로 결정되는 인터페이스를 (API)를 구체적으로구현한다.
• 다음상태가 결정되면 Context 에 상태 변경을 요청하는 역할도 한다.

Context

• State를 이용하는 시스템 시스템 상태를 나타내는 State 객체를 합성(Composition)하여 가지고 있다.
• 클라이언트로부터 요청받으면 State 객체에 행위 실행을 위임한다.

클래스 구성

클래스 흐름

특징

사용시기

• 객체의 행동(메서드)가 상태(state)에 따라 각기 다른 동을 할때
• 상태 및 전환에 걸쳐 대규모 조건 분기 코드와 중복 코드가 많을 경우
• 조건문의 각 분기를 별도의 클래스에 넣는 것이 상태 패턴의 핵심
• 런타임단에서 객체의 상태를 유동적으로 변경해야 할때

장점

• 상태에 따른 동작을 개별 클래스로 옮겨서 관리 할 수 있다.
• 상태와 관련된 모든 동작을 각각의 상태 클래스에 분산시킴으로써, 코드 복잡도를 줄일 수 있다.
• 단일 책임 원칙을 준수할 수 있다.(특정 상태와 관련된 코드를 별도의 클래스로로 구성)
• 개방 폐쇄 원칙을 준 수 할 수 있다.( 기존 State 클래스나 컨텍스트를 변경하지 않고 새 State를 도입)
• 하나의 상태 객체만 사용하여 상태 변경을 하므로 일관성 없는 상태 주입을 방지하는데 도움이 된다.

단점

• 상태 별로 클래스를 생성하므로, 관리해야할 클래스 수 증가
• 상태 클래스 갯수가 많고 상태 규칙이 자주 변경된다면, Context의 상태 변경 코드가 복잡해지게 될 수 있다.
• 객체에 적용할 상태가 몇가지 밖에 없거나 거의 상태 변경이 이루어지지 않는 경우 패턴을 적여ㅛㅇ하는 것이 과도할 수 있다.

옵저버 패턴은 옵저버(관찰자)들이 관찰하고 있는 대상자의 상태가 변화가 있을 때마다 대상자는 직접 목록의 각 관잘자들에게 통지하고, 관찰자들은 알림을 받아 조취를 취하는 행동 패턴이다.

이 패턴은 여타 다른 디자인 패턴들과 다르게 일대다(one-to-many) 의존성을 가지는데 주로 분산 이벤트 핸들링 시스템을 구현하는데 사용. Pub/Sub(발행/구독) 모델로도 알려져 있기도 하다.

구조

ISubject

• 관찰 대상자를 정의하는 인터페이스

ConcreteSubject

• 관찰 당하는 대상자 / 발행자 / 게시자
  • 옵저버들을 리스트(List, Map, set 등)로 모아 합성(Composition)하여 가지고 있음
  • Subject의 역할은 관찰자인 Observer들을 내부 리스트에 등록/삭제 하는 인프라를 갖고 있다. (register, remove)
  • Subject가 상태를 변경하거나 어떤 동작을 실행할때, Observer 들에게 이벤트 알림(notify)를 발행

IObserver

• 구독자를 묶는 인터페이스 (다형성)

Observer

• 관찰자 / 구독자 / 알림 수신자
• Observer들은 Subject가 발행한 알림에 대해 현재 상태를 취득한다.
• Subject의 업데이트에 대해 전후 정보를 처리한다.

옵저버 패턴은 여타 다른 디자인 패턴과 똑같이 상호작용할 객체를 합성(Composition)을 하고 메서드 위임을 통해 구성하는 코드 패턴임은 똑같지만, 핵심은 합성한 객체를 리스트로 관리하고 리스트에 있는 관찰자 객체들에게 모두 메서드 위임을 통한 전파 행위를 한다는 점을 기억하면 된다.

옵저버 패턴 흐름

• 옵저버 패턴에서는 한개의 관찰 대상자(Subject)와 여러개의 관찰자(Observer A, B, C)로 일 대 다 관계로 구성되어 있다.
• Observer패턴에서는 관찰 대상 Subject의 상태가 바뀌면 변경사항을 옵저버 한테 통보해준다. (notifyObserver)
• 대상자로부터 통보를 받은 Observer는 값을 바꿀수도 있고, 삭제하는 등 적절히 대응한다. (update)
• 또한 Observer들은 언제든 Subject의 그룹에서 추가/삭제 될 수 있다. Subject 그룹에 추가되면 Subject로부터 정보를 전달받게 될 것이며, 그룹에서 삭제될 경우 더이상 Subject의 정보를 받을수 없게 된다.

특징

사용시기

• 앱이 한정된 시간, 특정한 케이스에만 다른 객체를 관찰해야 하는 경우
• 대상 객체의 상태가 변경될 때마다 다른 객체의 동작을 트리거해야 할때
• 한 객체의 상태가 변경되면 다른 객체도 변경해야 할때, 그런데 어떤 객체들이 변경되어야 하는지 몰라도 될 때
• MVC 패터에서도 사용된다.
  • MVC 의 Model과 view 의 관계는 Observer패턴의 Subject 역할과 Observer 역할의 관계에 대응된다.
  • 하나의 Model 에 복수의 view 가 대응한다.

장점

• Subject의 상태 변겨을 주기적으로 조회하지 않고 자동으로 감지할 수 있다.
• 발행자의 코드를 변경하지 않고도 새 구독자 클래스를 도입할 수 있어 개방폐쇄 원칙(OCP) 준수한다.
• 런타임 시점에서 발행자와 구독 알림 관계를 맺을 수 있다.
• 상태를 변경하는 객체(Subject)와 변경을 감지하는 객체(Observer)의 관계를 느슨하게 유지할 수 있다(느슨한 결합)

단점

• 구독자는 알림 순서를 제어할 수 없고, 무작위 순서로 알림을 받음
  • 하드 코딩으로 구현할 수는 있겠지만, 복잡성과 결합성만 높아지기 떄문에 추천되지는 않는 방법이다.
• 옵저버 패턴을 자주 구성하면 구조와 동작을 알아보기 힘들어져 코드 복잡도가 증가한다.
• 다수의 옵저버 객체를 등록 이후 해지하지는 않는다면 메모리 누수가 발생할 수도 있다.

Memonto 기념물이라는 뜻

객체의 상태 정보를 가지는 클래스를 따로 생성하여, 객체의 상태를 저장하거나 이전 상태로 복원할 수 있게 해주는 패턴

구조

Originator 

• 상태를 저장하고 복원할 객체이다.
• 이 객체는 현재 상태를 나타내는 정보를 가지고 있다.

Memento

• Originator 객체의 상태를 저장하는 객체이다.
• Originator의 내부 상태를 나타내는 정보를 가지고 있다.

Caretaker

• Memento 객체를 관리하고 저장한다.
• Originator의 상태를 복원하기 위해 필요한 Memento 객체를 보관한다.

장점

• 객체의 캡슐화와 정보 은닉을 강화시킨다.
• 상태 복원 코드의 유지보수가 쉽다.

단점

• 메모리 사용량이 증가한다.
• 성능을 저하시킬 수 있다.

중재자 패턴은 모든 클래스간의 상호작용을 캡슐화하여 하나의 클래스에 위임하여 처리하는 패턴

구조

Mediator

• 여러 Colleague 객체들을 중재하는 인터페이스를 정의한 추상 클래스

ConcreteMediator

• Colleague 객체들을 가지고 있으면서 중재햐ㅐ주는 역할을 하는 클래스

Colleaguge

• Mediator 객체에 의해서 관리 및 중재를 받을 기본 클래스

ColleagueA, ColleagueB

• 실제로 Mediator 객체에 의해서 관리 및 중재를 받는 클래스를 구현한 클래스

사용 시기 

• 객체들 사이에 너 무 많은 관계가 얽혀 있을때
• 객체들 사이의 상호작용 관계가 복잡할때

장점

• 효율적인 자원관리 가능
• 객체간의 통신을 위해 서로 직접 참조할 필요가 없음
• 중재자 구현 클래스는 추후에 더 효율적인 클래스로 변경될 수 있음

단점

• 객체간의 통신 로직이 복잡해지거나 객체의 형태가 자주 변경되는 경우 유지보수 및 관리가 어려움