LabVIEW Development Best Practices Documents
This is part of a series of recommendations on how to implement some of the famous Gang of Four OOP design patterns using LVOOP. It represents an open discussion with the NI Community, so please feel free to provide comments and suggestions if you have any!
Intent
Extend a concrete object’s responsibilities dynamically. Extend the features of an existing class without refactoring tested code.
Motivation
When refactoring an application to add new features, it’s best to avoid digging into code that has already been tested. This pattern provides a means of extending an object’s functionality without changing the original class’s behavior. The pattern also solves the problem of defining a class whose objects may have any permutation of a set of responsibilities. It creates a scalable and recursive mechanism for defining that set and expanding it in the future.
Implementation
The attached example uses a coffee store for illustration: you could order your coffee black, or you could want to add double mocha and whipped cream to it. Instead of defining a set of n! subclasses to account for every possible type of drink, you can just define one subclass for each drink and condiment. The subclasses each contain one another and share the same list of methods as one another. When a method is called on an object, that object first calls the same method on its contained object. Then it appends that method’s output with its own data and outputs to the client.
This application can also be viewed as a feature addition to the coffee store after its release. The original coffee store sold simple coffee in four types:
Later, condiments were added. The condiments are also children of Beverage.lvclass, so they take the same data type as the original drink classes (Espresso.lvclass, etc.):
The condiments also have “Cost.vi” and “Get Description.vi” as dynamic dispatch methods, and they contain a single Beverage object as a data element. When a drink like Espresso is instantiated, it can be wrapped up (decorated) by a condiment like Whip. Then the client calls Whip.lvclass:Cost.vi to get the total cost of an espresso with whipped cream. This provides run-time feature extension of the basic drink classes, as well as a scalable means of defining new features with future releases of the software.
Editorial Comments
[David Staab] This specific example was converted from the Java code provided in Head First Design Patterns, Eric Freeman et. al. 2004. O'Reilly Media, Inc. See the Gang-of-Four text for an example using UI components instead of a world model.
NOTE: "DecoratorPattern_Revised_2013.zip" is a modified version of the first version that cleans up several oddities in the first version. The revised version avoids a whole bunch of replicated strings for the Description and changes how the Description gets generated so that the formatting is not left to each individual class. In the revised version, compare how the Condiment Decorator class computes the Description versus how it generates the Cost. These are two different common techniques for decorating an attribute. The Description is done by having a single method on the Condiment Decorator class that specifies how to reach inside the contained class. The Cost is done by having each class decide how to modify the cost. The second method is appropriate if you were going to have, for example, condiments that multiplied the overall price instead of just adding a value.
Daklu wrote:
Using patterns when they're not needed just makes the code more confusing.
I find this Decorator pattern confusing. In this example implementation, adding Whip effectively places the Beverage object inside the private data of the Whip object. Then adding Mocha places the Whip object inside the private data of the Mocha object. But what if you now need to change a property of the Beverage object? It's nested inside two owner objects and can't be easily accessed?
In the Derrick Snyder OOP Introduction (webcast here) he uses this example to demonstrate the Decorator pattern, with selection of a Beverage (Mild, House, Bold), set it's size (Tall, Grande, Venti), then add a modifier (Milk, Soy, Mocha, Whip). Once the modifiers (decorators) are added, the Beverage object is no longer accessible, so you wouldn't be able to change it's properties, such as the size, nor easily remove one of the Modifiers.
I know this is a simplified example, but there are weaknesses that make me wonder just how useful a Decorator pattern really is? And what would be a more appropriate OOP based solution to this problem?
DavidStaab wrote:
Daklu addressed this same concern about 3 comments above you guys:
Daklu wrote:
Your solution requires editing existing code. Decoration is used when editing the Beverage source code isn't an option.
In many environments, deployed code is immutable code and the only way to modify a deployed class is to decorate it.
Yes, I saw that, thanks. I understand now that this is just an example of how the decorator pattern might be applied, even though it might not be the best solution to this specific requirement. But in the Introduction to OOP webcast the Decorator pattern is specifically selected to demonstrate how to augment an existing set of classes. It seems this is the wrong approach, which begs the question: What is the correct approach for scaling an existing editable OOP design? Taking this 'Starbuzz' example where you do have the ability to edit what you like, how would one go about augmenting it to permit the addition of optional condiments? I see the arrayed approach mentioned by TheMadScientist above, but it seems a little bit non-OOPy to me. Are there other OOP-based approaches to achieving this? 
They're discussed ad nauseum in the GOF text. 
And, IMHO, I think there's a need to qualify identified "limitations" in the context of the pattern's use case and purpose. The Decorator pattern is presented in both the texts I read as a solution to modifying the behaviors of untouchable classes. The "limitation" of limit the mutability of the contained class is preempted by that purpose entirely.
The ability to set the description is not the same as the ability to actually store that description.
ALL decorators have the ability to Set Description. Some (Beverage) actually have a storage field for it. Others (Condiments) just forward it to their contained Abstract Beverage.
Consider the current set up. Suppose I decorate a Espresso with Whip. The outer class is a Whip object. What is that object's private data in memory? Well, it looks like this:
Notice that there are TWO string fields. If we decorate that drink with Milk then it gets worse:
We're using bytes that we don't need to be using AND we risk confusion in the code base about which string field is the Description for this drink. We really want there to only be one string field in the entire meta object.
