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’
Gentle Reader: This is one of those posts that begs for comments. It is partially tongue-in-cheek, so don’t get overly excited. However, since we do both produce products and provide services using OOP and design patterns, I thought it worth a cursory glance.
I’ve been refactoring a movie player/message board originally developed following the Where’s Waldo School of programming. It tucks ActionScript 2.0 in the Timeline in multiple frames, buttons, movie clips and God knows where else. The reason it’s an interesting project is because of excellent graphic design that I’m trying to maintain. Anyway, it’s almost done, and I was wondering whether refactoring using ActionScript 3.0 design patterns is a service or product.
When Services Became Products
Reading about the current economic meltdown in The Economist and watching the economic experts on TV, a couple of things became clear: (1) The major financial institutions have no idea what assets they have, and (2) a lot of the problems were caused because the assets were “re-packaged” into other “products.” Things became so convoluted that people like Bernard Madoff were able to buy and sell nothing to the tune of $40 billion and the SEC didn’t have a clue even when presented with evidence of a Ponzi scheme.
In order to avoid a similar meltdown in OOP programming, I thought it would be a good idea to ignite a discussion about the work we do and differentiate services from products. To begin, I thought I’d start with a list of products and services that seem to be pretty clear:
| Product |
| |
Service |
| External drive |
| |
Uninstalling Vista |
| Car |
| |
Washing car |
| Plum tree |
| |
Planting plum tree |
| Money |
| |
Doing tax returns |
| Computer game |
| |
Explaining how to win game |
Continue reading ‘ActionScript 3.0 Design Patterns: Service or Product?’
Bill Sanders
Recent Comments