Edwin,

The answer to keeping the interfaces in sync is to have both the Object and the Decorator classes as subclasses as an abstract class. This way, any interface changes are made to the abstract class and automatically filter to the subclasses.

Thanks

Rex

>>All,
>>
>>I want to use a Decorator pattern, but I have a question.
>>
>>If you chain functionality by using multiple decorators, don't you need a generic way to access that functionality, especially in any decorator not at the "end" of the chain.
>>
>>For example, I have an object, Object1 and two decorators, Decorator1 & Decorator2. Decorator1 has Function1 and Decorator2 has Function2.
>>
>>I instantiate a combination object with:
>>
>>loCombinedObject = CREATEOBJECT("Decorator1",CREATEOBJECT("Decorator2,CREATEOBJECT("Object1")))
>>
>>I now want to access This.Function2, but it does not exist. Function2 is accessed by This.oRef.Function2. What if I have more than just 2 decorators, I would have to know in what order the decorators were instantiated in order to access the decorator properties. I would need some sort of a generic routine to search the instantiation tree looking for the property/method.
>>
>>Am I making any sense, or have I overlooked something?
>
>Hi Rex,
> You are completely correct. The decorator pattern requires that you duplicate the entire interface of the class being decorated. If you apply multiple decorators where each one adds one or more methods you have two choices. Your first option is to predefine the order in which your target class is to be decorated and maintain all of the decorator interfaces accordingly. Your second option is to create a generic method that will search through the composite object until it finds a member which implements the requested method.
> Either approach will require some effort. If you decide that you must apply multiple decorators I would personally chose to create a generic method. IMHO keeping the interfaces of the decorator classes in sync would be too involved.
> Post some of the details of your task and perhaps we can find a better solution.
>
>HTH,
> Ned