-
프로그래밍에서 위임delegation의 기원은 오브젝트 합성object composition으로부터다. 오브젝트 합성은 간단한 오브젝트를 결합해 복잡한 오브젝트를 만드는 방법이다.
-
위임은 합성을 상속만큼 강력하게 만드는 방법이다. 위임에서는 두 객체가 하나의 요청을 처리한다. 수신 객체는 연산의 처리를 위임자delegate에게 보낸다. 이는 서브클래스가 부모 클래스에게 요청을 전달하는 것과 유사한 방식이다.
-
오브젝트 합성을 좀 더 재사용할 수 있게(상속같이 재사용되게) 하려면 위임 패턴delegation pattern으로 통합된다.
-
위임 패턴은 오브젝트가 헬퍼 오브젝트를 가질 수 있게 하며, 이 헬퍼 오브젝트가 델리게이트delegate라고 불린다. 이 패턴은 원래 오브젝트가 델리게이트 헬퍼 오브젝트로 위임해 요청을 처리할 수 있게 한다.
-
시간이 지남에 따라 위임 패턴은 상속의 좀 더 나은 대안으로 입증됐다.
상속
Note
|
상속은 코드 재사용을 위한 강력한 도구다. 특히 리스코프 치환 모델Liskov Substitution model의 맥락에서 말이다. 게다가 OOP 언어의 직접적인 지원은 이를 더 강력하게 만들었다. 그러나 상속에는 여전히 몇 가지 제한 사항이 있다.
|
Object Composition
Delegation
-
위임의 가장 중요한 장점은 런타임에 행동의 복합을 가능하게 하고, 복합하는 방식도 변경해 준다는 것이다.
-
위임의 단점은 객체 합성을 통해 소프트웨어 설계의 유연성을 보장하는 방법과 동일하게 동적인데다가 고도로 매개변수화된 소프트웨어는 정적인 소프트웨어 구조보다 이해하기가 더 엷다는 것이다.
-
그 이유는 클래스에 상호작용이 다 정의되어 있는 것이 아니라 런타임 객체에 따라서 그 결과가 다르기 때문이다.
-
또한 런타임에 비효율적일 수 있다.
-
이런 위임이 만들어 내는 복잡함보다 단순화의 효과를 더 크게 할 수 있다면 그 설계는 사용하기 좋은 설계이다.
-
그러나 이러한 유용성은 상황에 따라 다르고 얼마나 많은 경험을 갖고 있는가에 좌우되므로 위임은 고도로 표준화된 패턴에서 사용하는 것이 최상이다.
-
-
몇 개의 디자인 패턴은 위임을 부분적으로 사용한다.
-
상태state 패턴에서 객체는 현재 상태를 표현하는 상태 객체에 요청의 처리를 위임한다.
-
전략strategy 패턴에서 객체는 요청을 수행하는 추상화한 전략 객체에게 특정 요청을 위임한다.
-
이 두 패턴의 목적은 처리를 전달하는 객체를 변경하지 않고 객체의 행동을 변경할 수 있게 하자는 것이다.
-
방문자visitor 패턴에서, 객체 구조의 각 요소에 수행하는 연산은 언제나 방문자 패턴에게 위임된 연산이다.
-
-
위임에 전적으로 의존하는 패턴들도 있다.
-
중재자mediator 패턴은 객체 간의 교류를 중재하는 객체를 도입하여 중재자 객체가 다른 객체로 연산을 전달하도록 구현한다.
이때, 연산에 자신에 대한 참조자를 함께 보내고 위임 받은 객체가 다시 자신에게 메시지를 보내서 자신이 정의한 데이터를 얻어가게 함으로써 진정한 위임을 구현한다.
-
책임 연쇄chain-of-responsibility 패턴은 한 객체에서 다른 객체로 고리를 따라서 요청의 처리를 계속 위임한다.
이 요청에는 요청을 처음 받은 원본 객체에 대한 참조자를 포함한다.
-
가교bridge 패턴은 구현과 추상적 개념을 분리하는 패턴이다. 추상화와 특정 구현을 대응시키고 추상화는 단순히 자신의 연산을 구현에 전달한다.
-
Etc.
- Concrete Class
-
구상 클래스, 구현 클래스, 구체 클래스. 인스턴스와 다른게 무엇일까? Java에서
new
키워드를 통해 인스턴스를 만드는 클래스를 concrete class라고 한다. 이러한 클래스는 모든 함수가 구현되어 있어야 한다. abstract class와 대조적인 단어로 이해할 수도 있겠다.
참고
-
GoF의 디자인 패턴
-
함수형 코틀린