I agree that "design patterns should be a basic skill" of developers. I am not surprised that it isn't for most.

I have unknowingly used several Design Patterns in past efforts, often with slight variations. I can also understand when someone "speaks" in Patterns. Yet, I have only begun to "speak" in patterns. This is my slow climb of the learning curve.

Prior to understanding patterns, I feel my OOP was done with tunnel vision. I understood relationships amongst differnet objects, but it was hard to get an entire object graph in my head or on paper. Using Design Patterns, I feel I can genericize the actual objects into a series of roles and relationships common to an existing pattern.

I recently began working with an Agile consulting company. I now fully realize the benefit of Design Patterns in discussing architecture and implementation. How liberating!

I was a late adopter of unit testing (not to mention TDD). Once enlightened, I wondered how anyone could work without it. Two years on, I have come to the same conclusion about patterns.

I agree, they should be basic knowledge. Now, that said, I'm still learning them, and I've been developing software for a few years now. So, what's the trouble?

I suspect that part of the problem is that they are genuinely difficult concepts to grasp. Concrete vs. abstract objects + concrete and abstract creational objects can create a mix that will make your head spin. And that's just factories. Point is, it's not really easy stuff.

I also suspect that the GOF book was part of the problem. It was meant for architects, and is wonderful, but very esoteric, long and not an easy read.

Now, I think that the Head First book will really help. It's really amazing, and I think will help bring much of this all down to earth for all of us.

I also think that someone needs to draw a big fat line in the sand about where SOA and OO/Patterns are in relation to each other.

SOA between software boundries, OO inside them, or something to that effect. I'm not sure if I understand it all well enough to do that post, but it should be done by someone at some point...

Good post!

I think Refactoring can help a lot to educate people on patterns. I’ve just finished Martin Fowlers book on refactoring and now find Patterns like template method, state, strategy and composite, makes a lot more sense. I do agree that the GoF book is a bit of a struggle to read. Probably it would help to update the code samples to a more widely used modern language.

In Erich Gamma interview with Bill Venners he said:”You have to feel the pain of a design which has some problem and then it is an eye opener to realize that oh, actually this pattern, factory or strategy, is a solution to my problem. I guess you only appreciate a pattern once you have felt this design pain.”

It is like Ed Chapel said in his comment. Sometimes you find yourself the lone voice in a development company advocating the use of Patterns or Test-Driven Development. This can be extremely hard and most of the time you rather leave your existing company to join another agile development company to get more exposure on these techniques. I’ve also gone though this process…

You also have a lot Development Manager who’s grown up in the VB6 environment and they don’t keep up with the community’s movement towards OO concepts, and this causes friction.

You get questions like: “Why don’t you just pass in an array by reference and then use it to populate this list view?”

I’ve also seen some horrible code with twenty parameters on one method, all passed in by reference, populated in the method and then used in setting a views control values….lol

This is what I like to call the culture of VB!!

I would argue that along with design patterns, OOP isn't common knowledge. I think it should be, but I think the two go hand in hand. I see many people writing procedural code with a OO language. In fact, I don't remember the last time I saw an MSDN demo or sample that actually demonstrated an object-oriented concept. The examples are a procedural code snippet or a series of draggy droppies in the IDE. I've also seen just snippets of declarative markup, so the training that Microsoft has been putting out is not targeted toward OOP.

I read the GoF book and I don't have any problem in understanding them, I fully agree that this should be part of every developer education.
I consider understanding of design patterns about as basic as understanding inheritance and OOD.
After all, design patterns are really just clever uses of OOD principals.

That said, there are quite a bit of patterns that are simply not used very often.
The most used patterns, I think are:
* Command
* Strategy
* Singelton

Most of the others are usually implemented by the frameworks (for instance, I extended XmlWriter to add attribute-pre-line output - which was a case of using decorator).

I'm afraid your experience is fairly common. I'll readily admit I'm no pattern expert, but I'm getting better. Basic OOP concepts I do have down, but alas those skills are rare too. My last job attempted to hire only OOP experts, but yet all the code on the site was procedural, not to mention repetive, bloated and extremely hard to read. Most of the business logic was in stored procedures, and any "objects" in the application were merely data access code that returned datatables and readers.

The site was all in VB.NET. There was an 11 year programmer (5 years my senior) who didn't know how to use an interface or abstract class. Most of the other developers did not know how or when to use inheritance or composition.

Just like Maruis posted, Its a VB culture thing...

I'm not saying its "WRONG" but the RAD tools foster not understanding the system, but just building on it.

This is an important difference from "classic" frameworks of yesterday where it seemed you had to read the "framework's bible" to understand how to get "Hello World" to display.

Actually, I think to understand patterns properly, especially for most developers, they have to actually code them. Most developers appear to be experiential as opposed to visual learners, at least with code. This is the whole point of a Spike in Agile...to give you a trance to take the concept out for a spin.

Most developers, in my experince (mostly IT), do not often have the chance to code from a green field start. They have an existing system that they are modifying that has the "patterns" already in place.

I think the reason so few people adopt has to do with the fact that pattern usage goes through four phases before you become proficient in patterns.

1 - Acknowledge the existance of patterns.
2 - Apply patterns in code.
3 - Understand tools available and how to blend multiple patterns in code.
4 - Speaking in patterns.

Some people stick with it, while most don't.
I think this plays to Gary's point that typical IT developers get short-changed in developing these skills because they don't have the ability to apply patterns across an entire application.

Jeremy D. Miller brings up a point that I have been mulling over for many months now.
I am working in...

I think the most important tool I learned early on with the GoF book was the Design Pattern Relationships page at the back of the book.

My 2 cents: I've looked into the design patterns, spent several hours reading and downloading what I could find. Tried to find a concrete use, or even an example use and then hit the wall.

These sites do a great job of explaining the pattern in a environment of patterns. Unfortunately, most developers are developing in the real world, and a lot of us learn by example, whether we can admit that or not. Without concrete examples for me to see, all that pattern "stuff" is just that, stuff.

I'd like to add the caveat to your recommendation of Enterprise Integration Patterns:

If you are doing any sort of *message-based* SOA or EAI, then grab the EIP book.

Message-based is sort of implied by SOA and certainly by BizTalk, but not by EAI.

I don't like the fact that they called the book Enterprise Integration Patterns, since it's about messaging patterns and you don't always have to use messages for EAI. I firmly believe we should call a spade a spade. :)

Examples > patterns. Every time.

As a self-taught OO programmer with nearly ten years of "green field" OO projects, the biggest issue, for me, with GoF is the extra level of abstraction.

With OO it is difficult for many to visualize appropriate levels of abstracting a process or a file or a concept or a 'whatever' into one or more objects. That can often be overcome with dedication and persistence in learning basic OO concepts.

But when the "business logic" is no longer encapsulated WITHIN an object or set of objects and now becomes a function of the interactions BETWEEN objects, it becomes harder for many to grasp, myself included.

This is why I so enjoyed the EIP book. The patterns described there were so much more visual and concrete (no pun intended). I realized that it would be easier to discuss the concepts with coworkers, even those without an OO background. Also, the use of simple icons that work well in a "plumbing" metaphor, definitely helped ground abstract concepts in a very tangible way. I look forward to the possibliity of implementing some of these in the near future.

So why aren't design patterns common knowledge? In my organization it's mainly because we aren't rewarded for the effort that it takes to get there. I hope that this is finally starting to change.

The book "Refactoring to Patterns" by Joshua Kerievsky and the Refactoring book by Martin Fowler has helped me a lot in my knowledge of patterns. I recommend these books to anyone who wants to become a better OO and Agile developer. And like any TDD developer knows, it helps with the third mantra of Test - First Development...
What's also nice about Joshua's book is that he uses real world examples.

A couple of weeks ago in a bit of frustration I asked the question “Why aren't design patterns common...

Design Patterns are greatly over-hyped. They solve problems that rarely occur in properly designed applications. I realize that most people work on existing projects, but that provides even *less* opportunity to use patterns.

The main point that most (if not all) design patterns miss is this: Simplifying then problem brings you closer to solving it then does complicating the problem.

I could go through each pattern and try to argue why its trivial, over-complicating or even absurd, but I'm sure these arguments have already popped into your head at some time. Here are some examples:

1. Singleton. It takes a true genius to take the most simple, basic idea (a global variable) and complicate it that much. Global variables have proven to be problematic in the past, so all this complexity attempts to resolve all those problems. Better bet: try to avoid global variables, including singletons.

2. Decorator. This pattern is an example of "do it because you can." The most basic tenets of OOP (i.e. IS_A vs. HAS_A) are thrown out the window for this pattern to allow inheritance to define attributes. That didn't strike anyone as bass-ackwards when they first read it?

3. Strategy. This pattern can be worthwhile, but why call this a pattern? I always called function-only objects "functors." If you are knowledgable about programming in general and OOP in particular, you can make an interface from which to derive functors, but that's been done long before we gave it the title "pattern."

Of all the patterns, the ones that are the most useful are the ones that we have been using before design patterns ever became popular.

The problem is that by calling what we do a design pattern, we limit ourselves to that definition. If I took the basic idea of a pattern and basterdized it for a particular application, it wouldn't be a pattern anymore (it would hopefully be better!).

I am a programmer (I consider myself good at my trade) and I don't use design patterns. Some of the best programmers I've met don't, either. Come to think of it, the programmers that do advocate design patterns tend to be below average. They force their design patterns on everything and complicate the design needlessly. The fact that they write bad code is probably just a coincidence.

I realize this has been said before, but you can't have a knowledge of design patterns without OOP. Sadly, most developers do not know OOP. There are many reasons for this, one being that languages such as VB haven't supported it well, the impedence mismatch with relational databases and the fact that when most of us started learning how to program, OOP wasn't around. Coldfusion, the scripting langauge that I started my web development career, completely lacked anything resembling OOP. So it took me a while to get out of the procedural and data centric approach into the OO view. Even now, in my 7 year of development, i'm still learning. Its hard to change to new ways of doing things, and more importantly, new ways of thinking about things. Read "Object Thinking" for more reasons why OO knowledge is so rare.

I'll agree that it should be a language all developers speak, I'll disagree with Rick that it over-complicates things or limits you. If you are inflexible, then of course it does - but wise and agile programmers will adapt to their reality. All patterns do is provide your opening move (chess?), ie, you start there, then you hit reality and adapt. To me that's all it is - some best practices that help you sketch out your architecture and design, you immediately find that it's an oversimplification, but at least you have factored things out from the outset by identifying moving parts. Not such a bad thing as part of your development discipline if you ask me.

Kolejna porcja linków związanych z wzorcami projektowymi. Nie wszystkie jeszcze zdążyłem przeczytać,...

I agree big time with you Jeremy! I am still green in the realm of enterprise development and I work all alone. As such, ease of administration and adaptability to changes is even MORE IMPORTANT, in some regards, to meeting proposed deadlines. I began steeping in design patterns a while ago and have been thrilled about how much easier it has been for me to adapt my code to changes due to false emphases or misunderstood business practices. Just "getting it done" isn't enough when you are playing architect, developer, analyst and QA all by yourself. Design patterns, once grasped, have enabled me to quickly meet complex requirements and know that the code isn't going to look like spaghetti in a year.

Fowler on Template Method

What and Why of Design Patterns