However, that said, it is a contest and we could have come up with this on our own. Thanks for the helper code, it is clear.

The little example is to show how you could create a many instances of a concrete decorator as you want and move them so that you could position them in such a way that they would not be exactly in the same position. So, you really wouldn’t be modifying the concrete decorator; rather you’d be placing the results in another Shape instance in a different position.

Take care,
Bil

I just thought we couldn’t modifiy the component at all from the client other than creating it.

Thanks for clearing that up,
Josh

You’ll have to forget the text for now; however, in looking at the reply to Josh’s query, you have the clue how to create lots of instances and move them around.

Best regards,
Bill

(BTW–It’s Bill — not William. I have to use the same name as the one on the book. However, it’s Bill.)

You can make as many instances as you want in the Client. Here’s a clue:

import flash.display.Shape;
——————

private var mover:Shape=new Shape();

——————
block = new ConcreteDecorator3(block);
addChild(block.getFigure());

mover = block.getFigure();
mover.x=-100, mover.y=10;
addChild(mover);

Take care,
Bill

What if we want multiple of the same component? Creating duplicate concrete components just with different x,y co-ordinates doesn’t seem like good practice?

Thanks,
Josh

I see your point about mentioning parameters and then disallowing them in the contest. Sorry for the confusion.

Here’s the point. The purpose of the contest is not to re-write the decorator per se. Rather it is to focus on just those elements in the design that are meant to be changed. In the case of the Decorator pattern, the concrete components and decorators are the change elements. You can add more; keep the same ones and change them or some combination of the above. The purpose of all of the design patterns is to arrange the components so that change comes easily where you want it to come.

When you begin changing the signature, the effects ripple through the whole program, and that defeats the purpose of the pattern. You want to be able to change certain things without disrupting the entire program. Yes, I could have made a more complex signature that would have provided more runtime flexibility, but it would have been more difficult to understand for those who are just learning the Decorator for the first time. The Lunch Bucket examples on this blog are a combination of simplicity and practicality to reveal what the pattern is meant to do. If I err on the example, I tend to do so on the side of simplicity. That can be frustrating for some, but my hope is that a larger group of people will see possibilities beyond the example itself.

So, for now, all changes are to a Shape—any Shape— and in the concrete component or concrete decorator. Likewise, you can add more concrete components and concrete decorators. However, you’ve given me an idea for another post that deals with more sophisticated operations that might be added to concrete components and decorators.

Kindest regards,
Bill