Why Learn about Patterns?

• Thinking and learning about design patterns is a great way to learn the ins and outs of Object Oriented Programming. If you’re not taking advantage of OO features in .Net or Java you’re missing out on a lot of the power of the languages. Patterns are also very important for SOA as well.


• A former colleague of mine used to say that design patterns are “if/then” killers. A lot of patterns shift variations to polymorphism. That might not sound that important at first, but it can do wonders to improve the quality of code (readability, testability, removing duplication, extensibility, etc.).


• Patterns are often a design shortcut. Design patterns are previously described solutions to reoccurring design problems. There isn’t that much new under the sun. Chances are somebody has faced a similar situation no matter what your design dilemma is. Familiarity with design patterns can be a key to unlocking the accumulated design knowledge of many other software designers. It’s kind of like how Optimus Prime had the “Autobot Matrix of Leadership” that held all the memories and knowledge of past leaders (or Mat Cauthon in the Wheel of Time for that matter). Geek points if you understand any of the previous sentence.


• Patterns happen. One of the comments on my previous blog post was that developers don’t learn about design patterns because they are never getting to do “greenfield” development and weren’t involved with the patterns used in the system. That’s probably true for a lot of developers, but the patterns are still embedded in the system. Recognizing the patterns in an existing system can aid in understanding the existing design. Maintenance development is just as much software development as writing new applications. It’s foolish the way we often denigrate maintenance coding.


• Communication. Patterns give developers a shared shorthand terminology to discuss design choices. When someone tells me that a method in an abstract class is a “Template Method,” that communicates a lot of information to me because I understand the intent of the pattern. Even if I didn’t know the pattern, I could quietly google the pattern on my own and understand what my peer is talking about. This benefit can be completely negated if the other developers are not familiar with the pattern in question. If you’re a lead developer, you might invest some time into explaining any design pattern you’re using to the other developers to create a shared understanding. I got into a heated discussion with a developer last year over my decision to use a composite pattern. In the end it turned out his discomfort was largely due to the fact that he wasn’t familiar with the composite pattern.


• Because you might have to be interviewed for a position by me someday and I think they’re important[:)]


• Spouting off patterns can impress the weak-minded.