-옵저버 객체
-콘크리트 객체
여러 객체들 사이에 상호작용이 많다. -> 결합도가 높아져서 재사용성이 안좋아진다.
->중재자 클래스를 중재자를 통해서 연관을 허물어준다.
중재자 패턴의 구조
- 위의 사진은 GUI에서의 중재자 패턴의 예제이다. 버튼은 각각 다른 객체를 가지고 있다. 그런데 이것을 클릭 할 때마다 GUI 객체에 값을 리턴 해주어야 하는데, 서로 연관성이 많이 있기 때문에 그것을 중재해줄 클래스를 만든 것이 CustomerGUI이다. 그리고 :BasicInfoGUI(중재자 콘크리트)에 GUI의 객체를 담아서 보내준다.
책임 연쇄 패턴
ex) 이메일 분류 전처리기 파일을 만든다 할때, 스팸 -> 팬메일 > 컴플레인 -> 신규설치메일로 메일을 분류 할것임. 이렇듯 하나씩 연쇄적으로 분류를 하는 것을 책임 체인 패턴이다.
사용자가 원하는 작업을 어떤 객체에 시킬지 모를때, 그 작업을 다룰 만한 객체들의 집합에 던져버리는 패턴
접근한 객체가 요구된 기능을 처리 할 수 있는지 없는지 결정
처리할수 있다면 처리하고 없으면 객체 집합의 다른 객체로 제어를 넘김
책임 체인 패턴과 비슷하여 차이점을 비교
- 책임 체인 패턴 방식은 미리 할 일이 정해져 있다면, 커맨드 패턴은 해야 할 일과 일의 순서를 리스트로 적는다. 결과적으로 책임 체인 패턴은 할 일이 정해져 있지만 그 일을 처리 할 객체가 정해져 있지 않고, 커맨드 패턴은 일은 정해져 있지 않지만, 일을 해야 할 객체가 정해져 있습니다.
ex) 음식 주문 과정
- 주문서 하나에 할 리스트를 적고 한번에 클리어 하겠다.
구현 : 커맨드 클래스 안에 명령을 캡슐화 되어 있어, 클라이언트가 Target(1) 또는 Target(2)를 고르면 action1 메소드를 통해서 Action1Command 객체의 execute 메소드를 실행하고 Command 클래스의 execute 메소드가 실행하여 클라이언트가 값을 리턴 받는다.
클라이언트는 커맨드 객체를 여러개 가지고 있는 집합 관계이다. 이러한 관계를 통해서 런타임에 커맨드의 사용에 따라 동적으로 바인딩하여 프로그램에 융통성을 확보했다.
이벤트로 구동하는 어플리케이션, 옵저버 패턴은 데이터가 변화되면, 변화가 알려지면 구동된다. 비슷하다.
옵저버패턴은 상태를 변수로 처리, 상태 패턴은 상태를 객체로 처리한다.
클라이언트가 Target을 누르면 doRequest() 메소드가 호출됨 TargetStateA ,B와 같은 콘크리트 객체가 TargetState 객체로 들어가서 Target에 대한 이벤트를 수행한다.
출처 : 한빛아카데미-객체지향 소프트웨어 공학