브리지 패턴

• 브리지 패턴을 사용하면 추상화된 부분과 구현 부분을 서로 다른 클래스 계층구조로 분리해서 그 둘을 모두 변경할 수 있습니다.
• 브리지 패턴의 장점
  • 구현과 인터페이스를 완전히 결합하지 않았기에 구현과 추상화 부분을 분리할 수 있습니다.
  • 추상화된 부분과 실제 구현 부분을 독립적으로 확장할 수 있습니다.
  • 추상화 부분을 구현한 구상 클래스가 바뀌어도 클라이언트에는 영향을 끼치지 않습니다.
• 브리지 패턴의 활용법과 단점
  • 여러 플랫폼에서 사용해야 하는 그래픽스와 윈도우 처리 시스템에서 유용하게 쓰입니다.
  • 인터페이스와 실제 구현할 부분을 서로 다른 방식으로 변경해야 할 때 유용하게 쓰입니다.
  • 디자인이 복잡해진다는 단점이 있습니다.

빌더 패턴

• 제품을 여러 단계로 나눠서 만들도록 제품 생산 단계를 캡슐화하고 싶다면 빌더(Builder) 패턴을 사용하면 됩니다.
• 반복 작업을 별도의 객체로 캡슐화해서 컬렉션의 내부 구조를 클라이언트로부터 보호할 수 있는 반복자 패턴과 똑같은 아이디어를 사용합니다. 계획표 작성을 객체(빌더)에 캡슐화해서 클라이언트가 빌더에게 계획표 구조를 만들어 달라고 요청하도록 만드는 거죠.
• 빌더 패턴의 장점
  • 복합 객체 생성 과정을 캡슐화합니다.
  • 여러 단계와 다양한 절차를 거쳐 객체를 만들 수 있습니다(팩토리 패턴은 한 단계에서 모든 걸 처리하죠).
  • 제품의 내부 구조를 클라이언트로부터 보호할 수 있습니다.
  • 클라이언트는 추상 인터페이스만 볼 수 있기에 제품을 구현한 코드를 쉽게 바꿀 수 있습니다.
• 빌더 패턴의 활용법과 단점
  • 복합 객체 구조를 구축하는 용도로 많이 쓰입니다.
  • 팩토리를 사용할 때 보다 객체를 만들 때 클라이언트에 관해 더 많이 알아야 합니다.

책임 연쇄 패턴 (Chain of Resposibility)

• 1개의 요청을 2개 이상의 객체에서 처리해야 한다면 책임 연쇄 패턴을 사용하면 됩니다.
• 책임 연쇄 패턴에서는 주어진 요청을 검토하는 객체 사슬을 생성합니다. 그 사슬에 속해 있는 각 객체는 자기가 받은 요청을 검사해서 직접 처리하거나 사슬에 들어있는 다른 객체에게 넘깁니다.
• 사슬에 들어있는 각 객체는 핸들러 역할을 하며, 객체마다 이어지는 객체가 있습니다. 주어진 요청을 처리할 수 있으면 직접 처리하고, 그렇지 않으면 다음 객체에게 넘깁니다.
• 책임 연쇄 패턴의 장점
  • 요청을 보낸 쪽과 받는 쪽을 분리할 수 있습니다.
  • 객체는 사슬의 구조를 몰라도 되고 그 사슬에 들어있는 다른 객체의 직접적인 레퍼런스를 가질 필요도 없으므로 객체를 단순하게 만들 수 있습니다.
  • 사슬에 들어가는 객체를 바꾸거나 순서를 바꿈으로써 역할을 동적으로 추가하거나 제거할 수 있습니다.
• 책임 연쇄 패턴의 활용법과 단점
  • 윈도우 시스템에서 마우스 클릭과 키보드 이벤트를 처리할 때 흔히 쓰입니다.
  • 요청이 만드시 수행된다는 보장이 없다는 단점이 있습니다. 사슬 끝까지 갔는데도 처리되지 않을 수 있죠(사실 이런 특성이 장점이 될수도 있긴 합니다).
  • 실행 시에 과정을 살펴보거나 디버깅하기가 힘들다는 단점이 있습니다.