[7월 14일 1교시] Bridge Pattern

TV용 리모콘을 생성한다.

리모콘(추상) - XCanvas 컨트롤러, PAVV 컨트롤러

(TV만 바뀌어도) 컨트롤러 종류가 너무 다양해서 항상 새로 만들어야 하는 문제가 생긴다.

 

리모콘(추상화 개념)과 TV(실제 구동)를 분리하자.

브리지 : 예를 들어 리모콘은 TV와 aggregation 되었다. 서로 cowork를 할 때 좋은 방법이다.

[리모콘]◇---------[TV]

 

Bridge Pattern

기능(리모콘)의 계층과 구현(TV, 구동)의 계층을 분리하여 다리를 놓음.

다른 말로 Handle/Body

 

※ 클래스 계층이 하나라면 "기능의 클래스 계층"과 "구현의 클래스 계층"이 하나의 계층 구조에 혼재하게 됨 -> 클래스 계층이 복잡해 진다.

기능을 추가할 때는 주로 수직적으로 상속을 함.

구현을 추가할 때는 AbstractClass만 상속하여 ConcreteClass 종류가 여러가지로 만듬.

 

해결책 : 분리만 하면 흩어지기 때문에 둘 사이에 Bridge가 필요하다.

 

※ MFC의 메세지 맵(state, command, object, function... 마음대로 조절)을 잘 분석하면 Chain of responsibility패턴에 응용 가능.

※ aggregation과 composition의 차이.

 

결론

인터페이스와 구현의 결합도 약화

Abstraction과 Implementor를 독립적으로 확장 가능.

상세한 구현 내용을 클라이언트로부터 은닉

 

Window에서 올바른 WindowImp의 인스턴스를 얻을 수 있는가?

Abstract Factory Pattern & Singleton