I second that and I think trying to create a composite object may be the wrong way to go; rather, have a manager class object to manage the instances of each decorator.

>Since nobody else took a shot at this I'll give it a try. Yes you make sense :), but your approach with the imbedded CreateObject("Decorator",Creat... ) is different from the way I would try to tackle this. I would opt for an AddObject (to put Decorator inside of concrete component). Or with consideration for VFP6 hiccups I've seen with AddObject, I might get sloppy (and deviate slightly from GOF way) and just make the decorator object a true aggregate via oDecorator property on component.
>
>I think for what your looking at doing with a decorator, I think there's 2 main considerations to pull from the GOF chapter.... Since Decorator only changes a component from the outside, the component doesn't need to know anything about it's decorators (If it has to know Function1 or Function2, then look at Strategy). And... unlike Adapter, Decorator only changes the objects responsibilities and NOT it's interface. By specifically adding Function1, Function2, ect. your changing it's interface. The component should be able to simply call FunctionX, and depending on which decorator is instantiated, FunctionX would run code in either Function1 or Function2.
>
>Does that help?