데코레이터 확장하기

Question

저는 데코레이터 패턴에 관한 위키 피 디아 문서를 참조하고 있었고 coffee making example이 정말 유용하다는 것을 알았습니다. 위의 예제를 포함하여 대부분의 데코레이터 패턴 예제에서 발견 한 것은 데코레이터가 계약서에 정의 된 것을 수정하는 것 이외의 고유 한 특성/메소드를 추가하지 않는다는 것입니다. 예를 들어 커피 만들기 예제의 Milk 클래스는 커피 계약에 정의 된 메서드 (getCost() 및 getIngredients())를 무시합니다. . Milk 클래스가 자신의 메서드 인 GetBrand() 또는 GetQuantity()를 추가하려는 경우 (클라이언트가 이러한 메서드에 액세스하려면 Milk 클래스에 인터페이스를 캐스팅해야 할 수도 있음). 아무 것도 필드/메서드를 데코레이터에 추가하는 것을 멈추지는 않지만, 여기서 내 질문은 계약서에서 동의 한 것 이외의 데코레이터에 필드/메서드를 추가하는 것이 좋습니다.

내 마음에 들었던 한 가지 해결책은 계약에 속성 사전 (모든 키 값 쌍)을 추가하고 각 데코레이터가 자신의 속성을이 사전에 추가 할 수 있다는 것입니다. 나중에 클라이언트는 키를 사용하여 속성에 액세스 할 수 있습니다. 문제는 컬렉션이 대부분의 클래스에서 비어있을 수 있다는 것입니다. 또한, 나는

이

프라 딥

Answer 1

을 모두 하라구요 ..

milk.GetBrand() 

이

milk.Properties.PropertybyName[cs_cost]. 

이 문제에 대한 의견을 공유하시기 바랍니다보다 더 읽을 생각 데코레이터 패턴의 의도 : 추가 resp 첨부 객체를 동적으로 에 매핑 할 수 있습니다. 데코레이터는 기능 확장을 위해 서브 클래스 화하는 의 유연한 대안을 제공합니다.

따라서 데코레이터 또는 장식되지 않은 타겟의 클라이언트는 동일한 계약을 통해 두 사람을 볼 필요가 있습니다. 따라서 데코레이터에 더 많은 메소드를 추가해도 "데코레이터 패턴"을 사용할 때 이점이 없습니다.

그러나 "데코레이터"라는 용어는 매우 일반적인 의미로도 사용됩니다 (데코레이터 패턴은 언급하지 않음). 따라서 여러분은 누군가 꾸미기에 대해 이야기하는 것을 듣는 것이 일반적입니다. 속성을 추가하여 대상을 장식하는 클래스에 속성/메소드를 추가합니다. 그러나 이는 Decorator 패턴이 아닙니다.