|
The Decorator Pattern
In order to describe a pattern, you explain the pattern's intent, the pattern's motivation, how the pattern is implemented, and any consequences from the pattern's use. To tie everything together, you present a UML diagram.
Intent
Again, referencing the GoF book to describe the intent of the Decorator design pattern:
"Attach additional responsibilities to an object dynamically. Decorators provide a flexible alterative to subclassing for extending functionality."
Some authors refer to decorators as "wrappers," because a decorator wraps itself around another object.
This article later explains why the Decorator design pattern provides a flexible alternative to subclassing as it demonstrates why subclassing can be dangerous.
Motivation
The motivation for the Decorator design pattern is to eliminate the consequences of excessive subclassing. For example, consider a sports application where we need to model some major sports leagues.
public abstract class Sports
{
}
public class Baseball extends Sports
{
}
public class Football extends Sports
{
}
This isn't an example of excessive subclassing and, for all anyone knows, this application won't grow into an example of excessive subclassing. Adding some of the other major sports such as basketball, hockey, and soccer is straightforward, and it's easy to predict common object behavior for all sports.
Excessive subclassing occurs when an application requires a more complex model. The model may need to account for all possible common object behaviors, and these behaviors can be difficult to predict. Even if you overcome the initial design hurdles, refactoring can be a major pain.
Consider an application that models employees in a laboratory environment. The kinds of employees include a principle investigator, a research technician, and an administrative assistant. Figure 1 is our initial UML diagram for this application.
Figure 1: The initial UML diagram for the laboratory employee application.
Here's some souce code to go along with the model:
public abstract class Employee
{
}
public class PrincipleInvestigator extends Employee
{
}
public class ResearchTechnician extends Employee
{
}
public class AdministrativeAssistant extends Employee
{
}
At this point, the model is very simple. But employees can have other roles aside from their regular work assignments—roles like computer security officer, blood drive canvasser, or safety captain. So, you should include these additional roles in your model. You can add more objects by extending the Employee class:
public class PrincipleInvestigatorAndComputerSecurityOfficer extends Employee
{
}
public class PrincipleInvestigatorAndBloodDriveCanvasser extends Employee
{
}
public class PrincipleInvestigatorAndSafetyCaptain extends Employee
{
}
public class ResearchTechnicianAndComputerSecurityOfficer extends Employee
{
}
public class ResearchTechnicianAndBloodDriveCanvasser extends Employee
{
}
public class ResearchTechnicianAndSafetyCaptain extends Employee
{
}
public class AdministrativeAssistantAndComputerSecurityOfficer extends Employee
{
}
public class AdministrativeAssistantAndBloodDriveCanvasser extends Employee
{
}
public class AdministrativeAssistantAndSafetyCaptain extends Employee
{
}
By continuing to extend the abstract Employee base class, the updated UML diagram looks like the one in Figure 2.
Figure 2: The updated UML diagram for the laboratory employee application.
Using this approach, you'll have to account for every combination of employee and employee roles. The number of combinations becomes unmanageable.
You may be tempted to solve the problem using multiple inheritance (in C++) or by implementing interfaces (in Java). But solutions like these aren't dynamic. You can define
public class AdministrativeAssistant extends Employee
implements BloodDriveCanvasser, SafetyCaptain
{
}
But then you're stuck with a big, bulky class—a class whose functionality doesn't adapt itself to each individual employee.
You can try adding fields to the Employee class:
public abstract class Employee
{
boolean isComputerSecurityOfficer;
boolean isSafetyCaptain;
boolean isBloodDriveCanvasser;
}
But that's not very useful. Adding fields solves only the bookkeeping problem. The fields keep track of employee roles, but the fields don't enforce appropriate behavior for each of the roles.
New on the Java Boutique:
New Review:
Time Management Made Easy with the Quartz Enterprise Job Scheduler
Why not just use the Java timer API? This open source scheduling
API boasts simplicity, ease-of-integration, a well-rounded feature
set, and it's free!
New Applet:
Reverse Complement
Reverse Complement is a simple applet that converts DNA or RNA
sequences into three useful formats.
Elsewhere on internet.com:
WebDeveloper Java
Lots of Java information on webdeveloper.com
WDVL Java
Thorough Java resource at the Web Developer's Virtual Library.
ScriptSearch Java
Hundreds of free Java code files to download.
jGuru: Your View of the Java Universe
Customizable portal with online training, FAQs, regular news updates, and tutorials.
| 
