It’s funny how when you begin to think about something, anything, it seems as though the whole world begins to think about it too. Case in point, throughout my years of learning about development, I honestly never really focused on patterns. I’ve worked with a lot of really smart people, and very talented developers and I get the impression they didn’t think of them either (I don’t really remember anyone saying “I am going to use the Abstract Factory pattern when designing this application.”) Perhaps they knew about the pattern and it’s implementation all along and it was simply never said formally, I’m not quite sure.
Recently, however, I’ve begun to think, read, and attempt to identify patterns and I’ve noticed everywhere I go, people are talking about patterns. It must have been there all along, but for whatever reason I blindly skipped over it. BTW, patterns have been around for a very long time, and were formally introduced by Christopher Alexander in the 1960’s, borrowed from his work in architecture. The Gang of Four tend to be the most influential of modern development patterns.
Well, now that my eyes and ears are tuned in, I see and hear about patterns almost every day. It’s become an indication of a developer’s skill-level (such as in interview questions), a backing for defending ones’ code (this is good practice because it follows XYZ pattern), a guide to possible solutions for common problems, and an eye-opening analyis of where code can be optimized, reused, and universally understood.
I’ve only just begun my education in design patterns, but I do have one suggestion for anyone who is considering learning and eventually implementing design patterns. Identification is key. First, identifying what patterns apply to what situations (when to use patterns to solve which problems), and second, what pattern is being currently used by looking at the code and if it is the right pattern to address your problem. Identification is the most important thing, above even actually implementing the pattern correctly; because a perfectly implemented pattern for the wrong scenario will just make things worse. So before you step into any code, understand what each pattern offers, and when to use it.
You can find more information on patterns all over the place, but I recently found a very well laid out description/example website at http://dofactory.com/Patterns/Patterns.aspx. I believe this is a company which makes educational material; I’m not advocating you pay for their services/material, I know nothing about them. But what I do like, is that it gives an descriptive explanation, UML diagram, basic example, realworld example, and a .NET specific example of each pattern; very slick!
If you would like to add more information about design patterns, I encourage you to add a comment below. Even if you have no intention on implementing official patterns, it might be great insight into your own code you do every day. You just might be implementing a singleton pattern and you don’t even know it!
Good luck, and happy coding!
Nicholas Barger's Blog 