This post is going to be short and sweet. I worked up a little application that you can see here. Also, I created an AIR version, and it now seems to work on Mac, Windows 7, Windows Vista and Windows XP. You’re welcome to download it here (AIR version) and put it someplace handy where you can quickly look up the main principles guiding OOP and design patterns.
Principles in Your Lunch Bucket
Here’s the whole idea of why I started this project in the first place. We need something that makes it easy to remember and use good practices at work. The posts reviewing OOP and DP principles on this blog is one resource, but something simpler (and sillier) would be helpful to have available when cranking out code under a deadline.
Yes, I practiced what is preached
When developing this little application, I started off the wrong way, and decided that no! Never again! I’d start off right, and it wasn’t any more difficult. I used a Strategy pattern, and later I’ll put the whole thing up here with an explanation of how this “work” project was done by following the dictums I was writing about.
So take a look and let me get your valuable (as always) feedback.
The OOP & Designs Pattern Principles: Ready for Work by William B. Sanders, unless otherwise expressly stated, is licensed under a Creative Commons Attribution-Share Alike 3.0 United States License.
Bill Sanders
Poof, I am no longer a coder. I am management.
Well, that’s.. uh.. nice. But am I right saying this does nothing at all? I mean, that this is just a flash that doesn’t even have animations, loading or whatever? If you wanted to do something as simple as that, why not make a HTML page?
Poof, back to being a programmer.
No, really. Design patterns for the sake of design patterns alone make no sense whatsoever. It’s true that making real examples wouldn’t really be the right thing.. or wait, would it?
You know, there’s one thing I miss in your book. We get all the parts but we never get it to make a car and run – at best we throw the part and exclaim gleefully “Oooh look shiny part is rolling”. And indeed, there’s little point in developing a smooth and balanced crankshaft if all you’re ever going to use it for is saying “Well this would go in the engine but to prove it’s working we’ll use it as a crowbar instead!”
What I’d LIKE you to do is create a complete application. First just write down the requirements, then write down what modules the application will have. And then once that’s done we take each module individually and ponder upon which design pattern to use in it’s case. Or which not to. And why. So that at the beginning we are presented with a problem and a set of solutions – we then consider what design pattern fits best, and why it’s closest relatives are inferior choices (or better yet, if they’re just as good, what made you personally choose this pattern over that one and under what circumstances would you choose the other one)
Module by module we (and by we I of course mean YOU) implement different design patterns and arrive at a complete working application. At this point most users would exclaim “Oh well, that’s fine’n all but I could have done it a dozen times faster” – and they ARE right. So here comes the point where we (ie. YOU) prove that design patterns are really the way to go.
At the point of a completed application comes a list of additional requirements, ’cause the fictious spoiled idiot client said so. For example, if we would be doing a simple CMS, the client could have by accident stumbled upon 2advanced.com and noticed flash anchor linking – the technology that allows you to bookmark specific sections of flash content. Of course since 2advanced has it, your (Gotta LOVE the exchange rate) 109 USD flash CMS ABSOLUTELY MUST have this feature as well. Then while you’re at it add history as well. Basically things that would destroy a classic hard-coded approach.
Once we receive the list of complaints and nags about the website we begin refactoring and explian exactly HOW to refactor modules, how and why. And point out it would be much harder if we used a hard-coded approach.
Hi Archont,
Love the ‘poof’ and all the good points you make. Before going on, let me say that for several years, I was in management. So I know management issues. Ironically, design patterns were developed with managerial concerns in mind. Developers were wasting a lot of time re-inventing the wheel because their code was not reusable and when changes were made it was Bug-City. This was costing lots of money (pick your favorite monetary unit) and some really smart management realized that this was a systemic issue and not an individualistic one among programmers. So smart management and smart developers got together and came up with principles to make code easier to re-use and update without having to chase down bugs. Others came up with designs that enforced the principles—-what we know as Design Patterns.
Quick note to management: Why not use HTML for the app? Nothing loaded and no animations. Well, pointy-haired manager, there are in fact elements loaded—-the SWF files. Didn’t even see them they were so quickly loaded. Animations? No problema, burro. Just stick them in the SWF files, but since the app didn’t need any dancing baloney; there are no animations. And by the way, by extending the abstract class east and west, we could also easily add loaders for text and XML. That would save a bundle in development time. Try that with HTML.
Why’s Everybody Picking on Us?
Some have groused to us, “Why don’t you use real-world examples?” (Say that in a high and whiney voice to hear what we hear.) First of all, we do. Chandima provided a real shooter game in the chapter on the Factory Method, and I provided a real video player in the chapter on the State pattern. (Did anyone notice the coincidence that Adobe came out with a video player component based on a state patternafter the DevNet article I did on the State pattern that was part of the State design pattern chapter?) If you look you’ll find others. Now you can’t expect us to have a giant app that takes up 100 pages as a single example? As it was, it took us over 500 pages so that most chapters have a series of examples that begin as abstract ones so that readers could understand the pattern and then followed up with concrete examples. (The one I did on the seven deadly sins and heavenly virtues was seen as practical by no one — well so much for your immortal souls!)
Second, the wonderful Head First Design Patterns book doesn’t exactly have what you’d call real-world examples either, but no one is complaining to them. I mean like the Strategy pattern for ducks flying and quacking–not to mention a rocket propelled duck! However, you sure can learn about the key principles of OOP and the different design patterns. That’s what we were doing. We’ve got nothing against real-world examples (especially since we do have them in our book–grrrr), but there’s a difference between writing a book to show that we can use an example that will do something and one that explains how to do anything the reader wants. The more specific the example, the narrower the audience to which the example appeals.(Likewise, take a look at the GoF book and tell me how many of those examples you can create something “practical” with by following just the sample program.)
Finally, we did address the issue of examples on this blog. (See Where’s the Real World: Design Pattern Examples in ActionScript 3.0). I don’t know of anyone who’s fretted over having the best level of examples as Chandima and I have. We’re very concerned about having the right mix so that readers of this blog can come to not only understand design patterns but also take them to work.
Since you mentioned 2advanced.com, I noticed that they’re still using a 2006 example with the promised project “Coming Soon.” I guess 2009 isn’t soon enough. (I love 2advanced too!)
Kindest regards,
Bill
Hi Bill,
I’m new to design patterns and to be honest struggling…
I have tried reading your book and the Head First one but have failed to complete either… I find I learn much quicker by doing rather than reading however this doesn’t really help with design patterns as my main issue is not knowing which pattern(s) should be used for the project in hand.
What might be helpful is some sort of look up table where I could say my module has these needs so I can see possible patterns to use… very much like your design patterns classification table (p61) but with a little more detail.
Is such a thing possible?
Would it help actually help someone like me..?
For the record I do enjoy your book and it’s often used for reference. I am learning all this stuff (largely via your book) albeit quite slowly :)
Unfortunately I think design patterns are best learnt through experience (trial and error).
Cheers
Bob
Hi Bob,
First of all, you might want to get the Head First Design Pattern poster (http://oreilly.com/catalog/9780596102142/) for a handy look-up–it’s got all the DPs in the HF Book and a little blurb on what each is. It also has the principles. (It does not have the Lunch Bucket Rules though!)
Second, I don’t think that anyone who is trying to understand design patterns is someone like you. Rather, I think you’re someone like us. It just takes time. Also, I think that the best way to start is with as many OOP Principles as possible. Use them like a mantra if that helps. A lot of people are talking about design patterns and ignoring the principles behind them. That usually means they do not fully understand the purpose of design patterns.
Third, design patterns (and OOP for that matter) are best understood by understanding the underlying concepts and trial and error. Unlike a lot of programming where trial and error gets results; design patterns and OOP require planning and forethought. You need to both get results and do it in such a way that the code is reusable and easy to change when new requirements are demanded.
Finally, to help us all out, I’m going to be explain the design pattern that was used for the application used for this post. It’s a simple ‘take-to-work’ pattern that loads external graphic and SWF files. I’ll provide all the code, and you can put it in your pocket and when you need to load external graphics or SWF files, you’ll have it. I hope to make it the first in a series of “Take-to-Work” design patterns.
Kindest regards,
Bill
‘So smart management and smart developers got together and came up with principles to make code easier to re-use and update without having to chase down bugs. Others came up with designs that enforced the principles—-what we know as Design Patterns.’
Hi Bill,
Thanks for your great book and blog. I have lot of trouble where I work convincing anyone, management or otherwise, of the truth of the above comment. Do you have any references to web or book or anything that explores this, simply or otherwise?
many thanks again,
Peter
Hi Peter,
That statement I made about the development of Design Patterns is based on what I’ve picked up at OOPSLA meetings and reading this that and the other thing. The management at IBM Research had a hand in it because they had so much experience in dealing with the cost of development and changes in software. As IBM moved into a ’service company’ mode a lot of that ’service’ was upgrading software, and to help keep costs down and quality up, they were very supportive of design patterns and hired Gamma right out of graduate school (if not before).
Grady Booch, Chief Scientist, Rational Software Corporation (who wrote the Foreword to Design Patterns) noted in introducing the book:
That’s not exactly a “sexy” sell, but it should be to anyone who really thinks about what goes on in software development. If you look at the great majority of commercial Web sites, they are temporary. New things get added and changed all the time. The more complex the sites, the more they need design patterns of some sort to manage change in complexity. When you start adding programming like ActionScript 3.0, Java, C# or just about any other programming language used on the Internet, the complexity is exponential.
Like you, Chandima and I may wonder why that’s such a hard sell. Even among some OOP veterans, you’ll find the attitude “What’s the big deal?” Well, consider Global Warming (or the watered down politically correct, Climate Change). There’s plenty of scientific evidence (not to mention the clearly melting polar ice cap) that indicates global warming on a scale not seen before in recorded history. It’s easier to believe otherwise. Then we won’t have to change our behavior. However, when places like the Maldives (highest point 7.8 feet [2.4 meters]) cease to exist because of rising water, no amount of ‘I told you so’ is going to help, and the 330,000 folks on the Maldives are going to have to re-locate. It may take 100 years, and so there’s no sense of urgency. (Or news footage of folks being gobbled up by the sea.)
With design patterns, you have to change your behavior. Rather than writing decent algorithms in an OOP context, you have to first architect your programs in a set of relationships that are a bit complex. Also, there’s the fact that bad software design does work. In the same way that sequential programming still works today as well as it did when it was introduced in the 1950’s, both procedural, and OOP programming without design patterns works just fine.
Lots of software exists on bad architecture. You can even update software on bad architecture, and while it may look like a Rube Goldberg creation, it still works. The problem with bad architecture is that it is more difficult to update, but it is easier to create in the first place. As a result, management and programmers can keep on doing the same old crap, and it still works.
The great irony is that a cogent argument can be made against Design Patterns—namely that change costs money. If programmers are going to start using design patterns, the initial design costs are going to be greater than doing it “the old way.” Obviously, such arguments are flawed because on the backend of the deal, they’ll be saving far more time and money with design patterns because the design is open to change and code re-use.
Rather than arguing with other programmers or management, it’s better to demonstrate it. If I build something using a design pattern, I just do it. Then when it comes time to change or update, I can do it in a jiffy. The whole point of the “Lunch Bucket” series is to take a design pattern to work. It’s not like you’re sneaking a virus in, and good architecture never hurt anyone. (The dual-Factory Method used for the Design Pattern Catalog I did, paid off big time when I added the Structural designs.)
Anyway, Peter, don’t fret. Design patterns aren’t going anywhere. Just tell your management that you hope your company’s competitors don’t adopt them first.
Kindest regards,
Bill
Hi Bill,
Many thanks for that comprehensive response.
I do appreciate the irony in me asking you to recommend an OOP website! But this excellent site of yours is not particularly appropriate for my problem – it assumes interest or at least open mindedness.
I have now discovered your ‘the three keys of good design’:
http://www.as3dp.com/2009/04/02/is-your-actionscript-30-design-good-the-three-keys-of-good-design/
That is very good and helpful for me personally and who knows, it may hit the right spot with some colleagues.
I suppose I am looking for a discussion, in some form or other, of the good reasons for thinking of things in an OOP way, that will have some clout – research papers or something of the sort, reporting objective measurement of time saved, clients pleased, annual balances UP!
Thanks again, I hope to stick around here and learn lots.
Peter
Hi Peter,
For the scientifically objective research articles here’s a good place to start–a 1998 article on using design patterns:
http://portal.acm.org/citation.cfm?id=286942.286952
The Association for Computing Machinery (ACM) is the granddaddy of computer organizations and the ACM Special Interest Group on Programming Languages (SIGPLAN) is the SIG where design patterns got their grip in a series of papers prior to the publication of GoF’s book.
Here’s another paper from the same source that looks at an evaluation of design patterns:
http://portal.acm.org/citation.cfm?id=227747
You can get student [let's face it, we're all students of programming] membership in ACM for about $19 for a year and have access to a huge number articles (many dry as the sands of the Sahara), but they’re what I think you want. Also you have access to 600 online books from Safari and another 500 books from Books24X7.
Here’s another one that should answer lots of questions and lead to other articles:
http://www.cse.wustl.edu/~schmidt/CACM-editorial.html
You can get it without being an ACM member.
Here are some others freely available as well:
http://www.developer.com/design/article.php/1474561/What-Are-Design-Patterns-and-Do-I-Need-Them.htm
http://www.artima.com/lejava/articles/reuse.html
http://www.javaworld.com/javaworld/jw-10-2001/jw-1012-designpatterns.html?page=1
Years ago when I used to fly, I saw one pilot with a T-shirt announcing,
Pilots, like physicians and others who have a high occupational opinions of their abilities, often do more damage to themselves than good by such arrogant proclamations. Most of the good OOP and design pattern programmers I’ve met are not that way. In fact, they seem to be far more receptive to new ideas and programming strategies than programmers possessing far less skill and experience.
In getting other programmers and management to adopt design patterns, I think that “nudge” is a better way than “push.” The way to nudge is through demonstration. Even if only a part of a program uses a design pattern, its benefits become apparent when time comes to change. The Lunch Bucket series provides a series of nudges.
Kindest regards,
Bill
Hi Bill,
Wow! thanks, I’ll review these and get back to you in … a few weeks?
Peter
Ît’s really strange. When you begin with design pattern and you are already interested in them you feel you are doing the right thing – but you do not see the advantage right away. You start using them in different situations, face moments where you have gone to far and what I am concerned I sometimes think it’s more practical for the “more advanced” coders in high level languages like C++ or java. Mainly because programs in these languages are more complex and just “bigger” causing that things like pattern matter.
When you advance in pattern (meaning you start to think about them right from the start when an architectural problem arises) you start to feel better because you now have some experience in your pocket about earlier projects where these pattern saved you time.
I do think that flash coders (the most of them) had not been involved in bigger projects which required architectural thinking and if they do not start with pattern from a personal interest they will not see the advantage. That’s why (including me) they lake of real world examples (whatever that means for them) and find it hard to abstract from “hello world” examples.
The purpose of my writing is that I do not think that real world examples do help anyone better than abstract ones without experimenting with pattern on your own. It really needs time until you “feel” the advantage.
Everyone says “do not use pattern just to have them used”. I claim: Thats bullshit (for beginners). I say: Use pattern where ever you can if you want to advance using them. How should a flash coder get it’s experience when he is not a lucky one being involved in application development using actionscript?
I even used pattern in a screensaver I had to build recently. I built a chain of responsibility to handle different events based on the current date. I could have build it in a different way without so much classes and it would have been easier for non pattern related persons, but I wanted to use them to see the advantage or disadvantage at the end.
My personal advice: Do so, if you start using pattern. The old rule of “getting your hands dirty”.
Hi Mark,
I totally agree with you. If you wait around for a really big application to drop in your lap, it may be too late. Practice, practice, practice is the key to getting design patterns. It may seem like using an elephant gun to swat a fly, but if you can handle a little application, the big ones are just more of the same kind of thinking.
Currently, I’m working on an application re-using a Factory Method for a data provider. I’m thinking, why not build a button factory?
I’ve written several Video players using a State design pattern, but I like to try different things; so in addition to a State design, I might try something else, just to keep sharp.
Thanks for you wise comment,
Bill