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

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”.

Wow! thanks, I’ll review these and get back to you in … a few weeks?

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,

If you ain’t a pilot, you ain’t s**t!

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

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

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:

First, it shows the role that patterns can play in architecting complex systems. Second, it provides a very pragmatic reference to a set of well-engineered patterns….

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,

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

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

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