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!’
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’
In the little AIR menu with the 10 principles one of the clearest is the Open/Closed Principle. At one time this principle suggested that all updates be created using an implementation or extension of virtually any class. That could get tricky, especially if someone understood that to mean implementing an update or extending a subclass. However, later, the extension came to mean the extension of an abstract base class. In other words the interface is extended but never modified. Given these caveats, we can understand the basic principle as it is now understood:
Classes should be open for extension but closed for modification.
Easy to Take to Work
(Note: In talking about a program and changes, we’re not including the Client class. It just makes requests, and you can add requests and change them all you want in the Client.)
The idea that when you want to change a program, the only way you are able to make changes is by extension may seem a little restrictive. However, what the principle is really doing is providing a way to make changes without having to rewrite the whole program. The dictum, New behaviors are only available through extension should not be phrased in a way to make it sound like it’s tying your hands. Rather, it should say something like,
Hey! The Open/Closed principle makes it easy to add new behaviors without having to mess up your whole program.
Continue reading ‘Design Pattern Principles for ActionScript 3.0: The Open/Closed Principle’
Recently on this blog I created a little application to be used for a quick lookup of the different principles used in both OOP and Design Patterns—The Lunch Bucket Rules. The app uses a Strategy design pattern that is both simple and practical. The pattern is designed to load external SWF and graphic files (.gif, .png, and .jpg) and nothing more. You can pop it on a USB drive and put it on your keychain, and you’ll have a simple design pattern that you can take to work and use whenever you want. If you need a simple design pattern starting point, this should do the trick. (You can download the whole thing, including source code and swf files if you like.)
Swiss Army Knife of Design Patterns: The Strategy Pattern
The Strategy pattern defines a family of algorithms, encapsulates each and makes them interchangeable. Figure 1 shows the basic look of the Strategy pattern:
Figure 1: Strategy pattern Class Diagram
An interface (Strategy) describes the abstract signatures for the algorithm to be used with a family of algorithms. The key here is understanding that when developing a Strategy pattern that you need to think through the implications of the abstract methods you’ve got as part of a cluster of related algorithms. Given that this example only has a single Concrete Strategy class, you can assume that you have an opportunity to add more concrete strategies, and at the end of the post I’ll suggest a few.
Continue reading ‘ActionScript 3.0 Easy and Practical Strategy Design Pattern’
Bill Sanders
Recent Comments