디자인패턴...Delegation 편

Delegation (위임)
   : 합성을 상속만큼 강력하게 만드는 방법.

장점
   - Runtime에 행동의 복합을 가능하게 하고, 복합하는 방식도 변경해 준다.

단점
   - Runtime이므로 동적이다.
   - 고도로 매개변수화되어 있으므로 정적인 구조보다 이해하기가 어렵다.


Delegation이 사용되는 디자인 패턴들
전적으로 Delegation사용
   - Mediator (중재자)
     : 객체 간의 교류를 중재하는 객체를 도입하여 중재자 객체가 다른 객체로 연산을 전달하도록 구현, 연산에 자신의 참조자를 함께 보내고 위임받은 객체가 다시 자신에게 메세지를 보내서 자신이 정의한 데이터를 얻어가게 함

   - Chain of Responsibility (책임 연쇄)
     : 한 객체에서 다른 객체로 고리를 따라서 요청의 처리를 계속 위임
     요청을 처음 받은 원본 객체에 대한 참조자를 포함

   - Bridge (가교)
     : 구현과 추상적 개념을 분리하는 패턴
     추상화와 특정 구현을 대응시키고 추상화는 단순히 자신의 연산을 구현에 전달

부분적으로 Delegation사용
   - State (상태)
     : 객체는 현재 상태를 표현하는 상태 객체에 요청의 처리를 위임

   - Strategy (전략)
     : 객체는 요청을 수행하는 추상화한 전략 객체에게 특정 요청을 위임

   - Visitor (방문자)
     : 객체 구조의 각 요소에 수행하는 연산은 언제나 방문자 객체에게 위임된 연산


결론
   : Delegation은 객체 합성의 극단적인 예로서, 고도로 표준화된 패턴에서 사용하는 것이 최상이다.



참조문헌
- GoF의 디자인패턴

디자인패턴...재사용방법 편)

재사용방법

1. 클래스 상속
 - 화이트박스 재사용이라고도 불리운다.
 - 장점
   ① 컴파일 시점에 정적으로 정의되고 프로그래밍 언어가 직접 지원하므로 그대로 사용
   ② 부모 클래스의 속성 및 함수를 재사용, 자식 클래스에서 재정의로 수정이 쉽다.

 - 단점
   ① 런타임 시점에 상속받은 부모 클래스의 구현을 변경할 수 없다.
   ② 부모 클래스에 종속되므로, 부모 클래스 구현에 변경이 생기면 자식 클래스도 변경해야 한다.
   ③ 상속 시 부모 클래스의 내부가 보이므로 캡슐화에 위반된다는 의견도 있다.

 - 해결책
   ① 추상 클래스를 상속받는다. 구현이 아닌 인터페이스를 상속받는 것이므로 유연하다.

2. 객체 합성
 - 블랙박스 재사용이라고도 불리운다.
 - 한 객체가 다른 객체에 대한 참조자를 얻는 방식으로 런타임에 동적으로 정의됨
 - 인터페이스 정의에 주의
 - 객체는 인터페이스에서만 접근하므로 캡슐화 유지, 종속성 감소


결론
GoF에서는
 "객체 합성이 클래스 합성보다 더 나은 방법이다."
라고 표현하고 있으며, 상속과 객체 합성이 적절히 조합되어야 완벽한 재사용이 된다고 한다.




참조문헌
- GoF의 디자인패턴