책임 패턴은, 객체의 책임을 중앙 집권화하고, 확대, 제한하는 기법을 사용하는 패턴이다.
그 종류에는 아래 다섯 가지가 있다.

• 싱글톤 패턴
• 옵서버 패턴
• 중재자 패턴
• 프록시 패턴
• 책임 체인 패턴

1. 싱글톤 패턴

배경(문제상황-해결방안)

오직 하나의 인스턴스만을 생성해 이에 접근하는 메소드를 제공하기 위할 때 사용된다.
객체 하나만을 만들어서 그 객체 하나만 접근하게 하도록, 다른 사람이 여러 개를 만들 지 못하도록 안전장치를 만드는 것이다.

구조/설명

• 특징

생성자를 protect나 private로 선언한다.

• 적용 방법

1. private 정적(static) 변수 선언
2. 생성자를 private으로 만든다
3. 정적 public 메소드 정의

• 구조

1. 싱글톤 패턴과 더블체크 로킹 패턴
공통점: 둘 다 매우 간단하고, 자주 사용된다. 클래스에 하나의 객체만 생성됨을 보장한다.
차이점: 싱글톤 패턴은 단일 스레드 application에 사용되며, 더블체크로킹패턴은 다중 스레드 application에 사용된다.

2. 더블체크 로킹 패턴
싱글톤 패턴의 문제인 "단일 스레드 애플리케이션에만 적용 가능함"을 해결하기 위해 더블체크로킹패턴이 생겼다.
멀티스레드 애플리케이션에서 서로 다른 getInstance() 두 개의 호출이 동시에 발생하면 문제가 생긴다.
-> 더블체크 로킹으로 NULL 테스트 후 동기화하여 아직 인스턴스가 생성되지 않았는지 재확인한다.

2. 옵서버 패턴

배경(문제상황-해결방안)

객체 사이에 1대 n의 의존관계이며 객체 상태의 변화가 다른 의존 객체에 통지되고 자동으로 업데이트되게 함

구조/설명

publisher-subscriber라고도 불림
자동으로 통지를 처리해서 통보하는 쪽과 통보 받는 쪽의 결합이 약해진다.

• 특징
  subject와 observer 간의 결합
  subject는 단지 observer의 리스트를 가지고 있다는 정도만 안다
  subject와 observer가 서로 독립적으로 변경/확장될 수 있다
  subject가 observer를 관리하는 방식
  subject 객체가 observer의 레퍼런스를 포함하는게 가장 간단하다
  subject가 많고, observer가 적다면, 해시테이블을 사용할 수 있다
  하나 이상의 subject를 관찰
  observer가 여러 subject의 정보를 원하면 구현한다
  변경 통지가 왔을 때, Update()함수의 인자로 통지를 보내는 subject 객체를 넘김으로써 어떤 subject에서 온 통지인지 확인한다.

• 동작과정

1. 옵서버를 같은 방법으로 동작하게 만든다
2. 옵서버를 등록시킨다. subject에 아래 두 메소드 추가
   a. attach(Observer) : 옵서버를 리스트에 추가
   b. detach(Observer) : 리스트에서 옵서버를 삭제
3. 이벤트가 발생할 때 옵서버에게 통지
   a. 각 옵서버는 update를 호출하는 메소드 구현
   b. subject는 notify 메소드 구현 -> 옵서버 리스트를 따라 순회하며 각 옵서버에게 update 메소드 호출
4. subject로부터 정보를 받아옴

• 구조
  전체적인 구조(메소드 포함)이 모두 옵서버 패턴이라 모두 알아두어야 함
  
• 동작
  시퀀스 다이어그램으로 옵서버 패턴의 동작 파악
  subject : 데이터를 가지고 있는 워크시트
  - attach : 옵서버를 등록하는 메소드. 리스트에 추가
  - detach : 옵서버가 이제 사용안할때. 리스트에서 옵서버 삭제
  - notify : 통제 / 객체들에게 통지
  observer-그 데이터를 갖다 이용하는 애
  concreteSubject :
  ConcreteObserver :
  

예시

E-Commerce 새로운 고객 처리

• 고객에게 환영 email 보내기
• 고객의 주소를 우체국 통해 검증

3. 중재자 패턴

배경(문제상황-해결방안)

적용
객체 간 상호작용이 복잡하여 서로간의 의존관계가 구조화되있지 않을 때
하나의 객체가 많은 다른 객체들을 참조하고 있어 재사용하기 어려울 때
여러 클래스에 분산된 행위를 많은 서브클래스 없이 재구성해야 할 때

문제: 부품 객체들이 서로 강하게 연결되어 있음
- 한 부품의 class가 변경된다면 연관된 class들의 수정이 필요
- 새로운 부품을 추가하려면 코드 변경이 어려움
- 강하게 연결된 객체들을 약하게 연결할 필요가 있음

해결방안으로 "각 부품 객체들간의 상호작용을 도맡아 처리하는 객체(Mediator)"를 생성하여,
부품객체들 간의 연결을 느슨하게 만든다

구조/설명

여러 객체들 간의 상호작용 자체를 캡슐화한다

특징

각 객체들을 Mediator 객체를 제외한 다른 객체는 알지 못한다
객체 간의 상호작용은 Mediator가 처리한다
Mediator는 M:N의 객체관계를 M:1로 전환한다

구조

장점

기존 부품 클래스가 변경되거나 새로운 부품 클래스가 추가될 때 Mediator만 수정하면 된다
객체 간 직접참조를 피해 연결강도를 줄인다(loose coupling = 결합도를 줄임)
객체들과 독립적으로 상호작용을 변경할 수 있다
행위의 확장이 필요한 경우 Mediator class에 대해서만 새로운 하위 class를 정의할 수 있음

단점

Colleague 객체들 간의 상호작용을 Mediator 객체 하나가 모두 담당하기 때문에 Mediator 객체가 복잡해져 유지보수가 어려울 수 있다