An Enigma Wrapped in a Clear Casing
The Decorator Design Pattern is an enigma wrapped in a perfectly clear casing. I can think of fewer design patterns that are clearer in terms of what they do or seem more practical. By using concrete decorations, you can change an object without touching its structure. You can pick and choose what features you want to add, and your central object (or Concrete Component) is untouched. You want to add another feature? ¡No problema! Just add another decoration. Likewise, if you want to remove an unwanted feature, just remove the decoration you no longer want. All of this changing is accomplished without touching the object all the while the object is effectively changed by the decorations. So updating is simply a matter of changing decorations and/or adding new components to be decorated. (Download all files for program here )
In our book, the most real world practical example was a car dealership where different models of hybrid cars (Components) were set up with different accessories (Decorators) to arrive at a final price. As different models of hybrids became available, they could be added to the components and as different accessories came and went, they could be added to the program without having to disrupt the structure of the program. The pricing of the car was based on both on the base price (Component) and the whistles and bells (Decorators) the buyer selected. Once set up, the site is easy to maintain, update and reuse in a different context.
In this post we want to provide a simple yet usable example that can be modified for your own needs. Many of the simple examples we’ve seen (or created ourselves) have made extensive use of string and numeric variables and/or trace output. Given the fact that practical applications make extensive use of such variables, there’s nothing wrong with that. However, we’ve found that the most difficult part of creating design patterns with ActionScript 3.0 is in making use of graphic materials and movie clips.
Continue reading ‘ActionScript 3.0 Easy and Practical Decorator Design Pattern’
The Contest
Okay, here’s a chance for Fame and Fortune. (We’ll supply the former; you supply the latter.) On Monday, April 27 you’ll find a new ActionScript 3.0 Easy and Practical Decorator Lunch Bucket Pattern on this blog. The contest will begin on Monday, April 27 and end Friday May, 22–2009. (That’s not a lot of time! But it should not take a lot of time to make the changes.) You can download the Decorator files here .
The contest is to see if you can change the Decorator design pattern in the new post, ActionScript 3.0 Easy and Practical Decorator Design Pattern.
Using the provided Component class (no changes allowed) and the provided Decorator class (no changes allowed) add new or changed Concrete Components and/or Concrete Decorators to make the most interesting program using the Decorator Design Pattern.
We have four age categories, and each category will have 1st, 2nd, and 3rd prizes. The Grand Prize will be given to the very best entry, regardless of age. Here are the categories:
- Under 18
- 18-25
- 26-40
- Over 40
All winners will be displayed on this blog along with their entries and photos. Read on to learn the rules.
Continue reading ‘ActionScript 3.0 Design Pattern Contest: The Golden Lunch Bucket Awards!’
For those of you who have developed applications where a reference drills down through a series of movie clips, the Least Knowledge Principle may seem a bit harsh. It is very easy and even shows a semblance of foresight and organization to arrange operations in a movie clip set to have each movie clip do one thing in a complex object. To get something working, though, you do not want to rely on drill-down references that visit each of the many movie clips. Statements such as,
myMC_high.myMC_middle.myMC_lower.myMC_lowest.DoSomething()…
break the principle of Least Knowledge because it implies that each has some knowledge of the inner workings of the others. Likewise, anyone who has spent much time with JavaScript and the Document Object Model (DOM) knows that many of the objects have some hefty drill-downs in references. According to the Least Knowledge Principle, these are all ways to ask for trouble. Let’s see why.
Continue reading ‘Design Pattern Principles for ActionScript 3.0: The Least Knowledge Principle’
Most of what we mean by the Dependency Inversion Principle has been discussed either in describing what a design pattern does in terms of relating components to one another or implied in other principles. However, I’ve found that the Dependency Inversion Principle acts as a helpful reminder to keep things abstract in working with instances that request functionality or extend a base class.
Unfortunately, the concept of inversion is only half the story and is used in reference to programming structures where a higher-level module depends on a lower-level module. One might be led to believe that the inversion occurs where lower level modules depend on higher-level modules only. Actually, the principle holds that
all modules of a program should depend on abstractions
Maybe a better name for the principle would be the Abstraction Dependency Principle. In any event, program modules should all depend only on abstractions. If you look at Figure 1 you can see a simple example where a Client instantiates a concrete class but depends on the abstract class for typing. Further, the concrete classes depend on the abstract class for implementation. Aggregations and associations would depend on the abstract base class instead of the concrete classes as well.
Figure 1: Depending on Abstractions
As you can see in both the diagram and code snippets, all dependencies are on the Abstract class. That’s what the principle means at its core. It’s not a difficult one, and it overlaps with lots of other principles we’ve discussed on this blog and in our book.
Continue reading ‘Design Pattern Principles for ActionScript 3.0: The Dependency Inversion Principle’
In looking for details about the Dependency Inversion Principle, I came across an article by Robert C. Martin in which he discusses a situation where one software developer looks at another’s application. Because I’ve had similar experiences, along with the exasperation developers feel for such comments, I thought I’d include it here—paraphrased as it were. He beautifully portrays the adolescent sniveling where the other’s comment is all too often,
That’s not the way I would have done it…
In several states I believe such comments are grounds for justifiable homicide. Not only is that kind of comment indicative of a certain type of nastiness, it is generally not helpful. Being as immature as the next guy, my general response is usually something like,
Okay smarty, how would you have done it?
This kind of brain-dead twittering misses the crucial point of what is good software design? Maybe I did indeed do it all wrong, but by what criteria do we judge good design? To some extend the answer lies in all of the discussion about OOP and Design Pattern principles we’ve covered on this blog and in our book. Martin provides a nice set of good design indicators that encapsulate much of our discussions.
Continue reading ‘Is Your ActionScript 3.0 Design Good? : The Three Keys of Good Design’
Bill Sanders
Recent Comments