Decorator design

Question

I'm pretty new with patterns, and I'm learning Pattern Decorator for the program I have to write.

Studying online, I found an example Decorator pattern (this is Java pseudo-code):

class Solution1 { static interface Component { void doStuff(); } static class MyComponent implements Component { public void doStuff() { // ... } } static class ComponentDecorator implements Component // This is the Decorator pattern. { private final Component component; public ComponentDecorator(Component component) { this.component = component; } public void doStuff() { this.component.doStuff(); } } static class ComponentDecorator1 extends ComponentDecorator { public ComponentDecorator1(Component component) { super(component); } private void doExtraStuff1() { // ... } public void doStuff() { super.doStuff(); doExtraStuff1(); } } static class ComponentDecorator2 extends ComponentDecorator { public ComponentDecorator2(Component component) { super(component); } private void doExtraStuff2() { // ... } public void doStuff() { super.doStuff(); doExtraStuff2(); } } public static void main(String[] args) { MyComponent c = new MyComponent(); ComponentDecorator1 cd1 = new ComponentDecorator1(c); ComponentDecorator2 cd2 = new ComponentDecorator2(cd1); cd2.doStuff(); // Executes Component.doStuff, ComponentDecorator1.doExtraStuff1, ComponentDecorator2.doExtraStuff2 } }; 

When I analyzed this example, I realized that in the past I made a very similar image, but in a different way:

 import java.util.*; class Solution2 { static interface Component { void doStuff(); } static class MyComponent implements Component { public void doStuff() { // ... } } static class ComponentDecorator implements Component // This is NOT the Decorator pattern! { private final List<Component> components = new ArrayList<Component>(); public ComponentDecorator() { } public ComponentDecorator addComponent(Component component) { this.components.add(component); return this; } public void removeComponent(Component component) // Can Decorator do this? { // ... } public void doStuff() { for(Component c : this.components) c.doStuff(); } } static class ComponentDecorator1 implements Component { public ComponentDecorator1() { } private void doExtraStuff1() { // ... } public void doStuff() { doExtraStuff1(); } } static class ComponentDecorator2 implements Component { public ComponentDecorator2() { } private void doExtraStuff2() { // ... } public void doStuff() { doExtraStuff2(); } } public static void main(String[] args) { ComponentDecorator cd = new ComponentDecorator(); cd.addComponent(new MyComponent()); cd.addComponent(new ComponentDecorator1()); cd.addComponent(new ComponentDecorator2()); cd.doStuff(); // Executes MyComponent.doStuff, ComponentDecorator1.doExtraStuff1, ComponentDecorator2.doExtraStuff2 } } 

In my opinion, the second example can be used in the same situations where you can use the Decorator template, but it is more flexible (you can, for example, remove or rearrange the components in the list), so my questions are:

• Is solution 1 (the correct decorator pattern) better than solution 2? Why?
• Is it possible to add functions to remove instances in solution 1?
• Is it possible to add functions to reorder instances in solution 1?

Answer 1

Solution 2 is actually a mixture between the decorator pattern and the composite pattern.

I think that solution 1 is better than solution 2 if you just want to add behavior and use solution 1 + a composite template is better if you also need to use multiple objects as one.

For a more general answer about using these two patterns, see The Difference Between a Composite Pattern and a Decorator Pattern ?

This is the key answer:

A composite template allows you to build a hierarchical structure (for example, a tree of elements) so that your external code can view the entire structure as a single object. Thus, the interface to the sheet object is exactly the same as the object for the composite object. Therefore, the bottom line is that all the elements in your composite structure have the same interface, although some of them are leaf nodes and others are whole structures. User interfaces often use this approach to simplify layout.

http://en.wikipedia.org/wiki/Composite_pattern

The decorator template allows the entity to completely contain another object, so using the decorator looks identical to the contained object. This allows the decorator to change the behavior and / or contents of what he encapsulates without changing the appearance of the object. For example, you can use a decorator to add log output to use the contained element without changing the behavior of the contained element.

http://en.wikipedia.org/wiki/Decorator_pattern

Answer 2

Is solution 1 (the correct decorator pattern) better than solution 2? Why?

Solution 1 is better than solution 2. Solution 1 follows the gang of the 4th design, as it is.

Solution 1 is

• Plain
• Less error prone than solution 2. You need to fill out the list and clear the list after use (which you are not currently running). If you use the same decorator in multiple threads, you need to protect your code from memory consistency.

A real world example of VendingMachineDecorator is available in this documentation @

When to use a decorator template?

Is it possible to add functions to remove instances in solution 1?

Yes. Maybe. You must add the delete function to abstract decorators and concrete decorators.

 public void removeStuff() 

You can see below SE questions:

How to remove a decorated object from a Decorator template in Java

Can you remove the decorator?