Observer (옵저버 패턴)

주제(Subject)가 변경될 때 마다 옵저버들에게 변화를 알려주는 디자인 패턴
한 객체의 상태가 바뀌면 객체에 의존하는 다른 객체에게 자동으로 내용이 갱신되는 방법으로 일대다(one-to-many) 의존성을 정의한다.

주제(subjet)는 옵저버들이 인터페이스를 구현하는 것을 제외하면 옵저버에 대해 아는게 없다. 따라서 이들의 결합은 느슨한 결합(Loose Coupling) 형태이다.

Subject 인터페이스

1. 옵저버의 등록, 제거, 변화를 알려주는 매서드가 있으며, 주제는 여러개의 옵저버가 있을 수 있다.
2. 주제는 상태가 바뀔 때마다 매서드를 통해 옵저버들에게 알려줘야한다.

Producer 클래스

1. Subject 인터페이스를 구현한 클래스
2. 고유한 상태 값을 가질 수 있음
3. 전체 상태 값을 변경하는 setData와 같은 매서드를 사용시, notifyObservers()와 같이 옵저버들에게 변화를 알려준다.
4. 상태값 각 필드는 getter 매서드로 구현되어있어, 옵저버들이 풀 방식으로 상태값을 직접 가져올 수 있다.

특징

1. 옵저버는 언젵튼 새로 추가 및 제거가 가능하다.
2. 새로운 형식의 옵저버를 추가할 때 주제는 변경이 필요 없다.
3. 주제와 오버저는 서로 독립적으로 재사용이 가능하다.
4. 주제나 옵저버가 달라져도 서로 영향받지 않는다.

장점 및 단점

장점
1. 주제와 옵저버 모두 인터페이스를 통해 느슨한 결합을 유지한다.
2. 옵저버 패턴에서는 구성을 활용해 관리하므로 확장성이 좋다.
3. 옵저버들은 서로 독립적이기 때문에 특정 옵저버가 문제가 생겨도 다른 옵저버에 영향이 없다.

단점
1. 옵저버 객체가 많아질수록 모든 옵저버 객체에 대한 처리를 하므로 성능 저하가 일어날 수 있다.

Startegy (전략 패턴)

정책 패턴(Policy Pattern)이라고도 불림
알고리즘을 정의하고 캡슐화 하여 각 알고리즘군을 수정해 사용할 수 있게 해준다.
객체의 행위를 변경하고 싶은 경우 직접 수정하는 것이. 아닌, 전략이라고 불리는 캡슐화한 알고리즘을 변경함으로 유연하게 확장하는 디자인 패턴이다.

구성

1. ConcreteStartegy(전략 알고리즘 객체들): 알고리즘 행위, 동작을 객체로 정의한 구혀네
2. Strategy Interface (전략 인터페이스): 모든 전략 구현체에 대한 공용 인터페이스
3. Context (컨텍스트): 알고리즘을 실행할 때 마다 해당 알고리즘과 연결된 전략 객체의 매서드를 호출
4. Client (클라이언트): 특정 전략 객체를 컨텍스트에 전달 함으로써 전략을 등록 및 변경하여 전략 알고리즘을 실행한 결과를 누린다.

전략 패턴 사용 시기

1. 전략 알고리즘의 여러 버젼 또는 변형이 필요할 때 클래스화를 통해 관리
2. 알고리즘 코드가 노출되면 안되는 데이터에 접근하거나 활용하고자 할 때
3. 알고리즘의 동작이 런타임에 실시간으로 교체가 필요할 때

장점 및 단점

장점
1. 알고리즘을 정의하고 캡슐화하여 런타임 시에 알고리즘을 선택하는 데 사용됨
2. 알고리즘을 쉽게 변경 및 대체할 수 있으므로 유연함
3. 알고리즘 추가 및 수정을 할 때 코드 수정이 최소화되므로 확장성이 높아짐
4. 알고리즘을 캡슐화했기에 코드 재사용성이 좋음
5. 각각 알고리즘을 독립적으로 테스트할 수 있으므로 용이함

단점
1. 추가적인 클래스 및 인터페이스가 필요하기에 코드 복잡성이 증가될 수 있음
2. 런타임 시에 알고리즘을 선택하는 데 추가적인 오버헤드 발생 가능
3. 전략패턴을 구현하는 것이 어려울 수 있으므로, 적절한 분석과 설계가 필요하다.

Composite Pattern (복합체 패턴)

객체들의 관계를 트리 구조로 구성해 전체-부분 계층을 표현하는 패턴으로, 사용자가 단일 객체와 복합 객체 모두 동일하게 다루게 하는 것을 컴포짙트 패턴 (복합체 패턴) 이라 한다.

즉 클라이언트가 단일 객체나 복합 객체를 동일하게 취급하는 것을 목적으로 한다.

특징

1. 일종의 구조 패턴이라고 불리며, 작은 클래스들을 상속과 합성을 이용해 더 큰 클래스를 생성하는 방법을 제공하는 패턴이다.

2. 독립적으로 개발한 클래스 라이브러리를 하나로 사용할 수 있으며, 여러 인터페이스를 합성해 서로 다른 인터페이스들의 통일된 추상을 제공한다.

3. 구조 패턴은 인터페이스나 구현을 복합하는 것이 아닌, 객체를 합성하는 방법을 제공한다. 따라서 런타임에서 복합 방법이나 대상을 변경할 수 있어 유연성을 가진다.

구성

1. Component
   클라이언트가 composition 내의 오브젝트들을 다루기 위한 인터페이스
   인터페이스 또는 추상 클래스로 정의되며, 모든 오브젝트들에게 공통되는 매서드를 정의한다.

2. Leaf Object
   컴포넌트를 구현하며, composition 내 오브젝트들의 행동을 정의한다. 이때 다른 컴포넌트에 대해 참조를 가지면 안된다.

3. Composite Object
   Leaf 객체들로 이뤄져 있으며, 컴포넌트 내 명령들을 구현한다.
   클라이언트가 composite 객체와 leaf 객체를 동일 취급할 수 있도록 composite object도 컴포넌트를 구현해야 한다.

leaf 그룹에 대한 동작 (add, remove 등..) 을 할 수 있는 매서드들을 클라이언트에 제공한다.

장점 및 단점

장점
1. 유연성
객체의 구조를 변경하는데 유용하다. 새로운 개별 객체나 복합 객체를 추가하더라도 클라이언트가 코드를 수정할 필요가 없으며, 객체 간 결합도를 낮춰 유연성을 높인다

2. 단순성
   개별 객체와 복합 객체를 동일한 방식으로 다룰 수 있어 클라이언트의 코드가 단순해진다.

3. 재사용성
   객체를 구성하는 방식이 일관성 있고, 재사용성이 높은 구조를 만들 수 있다.

4. 구조적 안정성
   복합 객체 내부의 구조를 안정적으로 유지할 수 있다. 복합 객체에서 개별 객체를 제거하더라도 객체 간의 관계가 깨지지 않는다.

단점
1. 처리 비용
복합 객체 내부의 모든 개별 객체를 처리해야 하기 때문에 처리 비용이 증가할 수 있다.

2. 설계 복잡성
   객체의 구조가 복잡한 경우에는 효과적이지만, 반대로 객체의 구조가 단순한 경우에는 오히려 설계의 복잡성을 증가시킬 수 있다.

3. 특정 상황에서의 한계
   개별 객체와 복합 객체가 서로 다른 인터페이스를 가지는 경우나, 복합 객체 내부 구조가 동적으로 변하는 경우에는 컴포지트 패턴을 사용하기 힘들다.