Monday, December 8, 2014

Software Design Patterns

Design patterns are architectural solutions to problems software engineers come across time and time again as they write programs. Many developers will go through their career without ever explicitly applying design patterns to their code, but they're usually present to some varying degree. Have you ever needed to instantiate a class only once? There's a design pattern (or antipattern) for that. Have you ever needed to encapsulate object creation and communication? That's been solved, as well.

When dealing with large-scale systems, they're downright necessary. If you don't take the time to plan out which classes should be responsible for what, where logic should live, and who is dependent on whom, you'll have a very brittle foundation for your application to rest upon. It helps to be aware of existing design patterns and how they can be leveraged to build the optimal system.

Applying Design Patterns

So how do you go about applying design patterns to your approach? Well, design patterns solve architectural problems inside the logic of your application. So you'll be planning this out before you write a single line. While the UI, UX, and other design considerations and user requirements will influence how you build out this logic, this has less to do with how the application looks and more to do with how the code is structured and maintained.

As I mentioned in the introduction, design patterns make their way into code either implicitly or explicitly to varying degrees. And while you'll see that the names of these pattern have been heavily influenced by architecture (Factory, Builder, Bridge, Adapter), don't let that force your into thinking they need to be applied, as is, to have a solid foundation. It's best to have a good understanding the problem they're attempting to solve because they may not always work for your application without some tooling. They exist to provide a set of guidelines for writing large scale, decoupled systems that are easy to update and make bug fixes to 6 months or 5 years from now.

Categories of Design Patterns

There are three major families of design patterns you should be familiar with. These are creational, structural, and behavioral and you'll find that each pattern that fall under each are very similar to one another. Take the time to study each model.


  • Abstract
  • Builder
  • Factory
  • Object Pool
  • Prototype
  • Singleton


  • Adapter
  • Bridge
  • Composite
  • Decorator
  • Facade
  • Flyweight
  • Private Class Data
  • Proxy


  • Chain of Responsibility
  • Command
  • Interpretor
  • Iterator
  • Mediator
  • Memento
  • Null Object
  • Observer
  • State
  • Strategy/Policy
  • Template
  • Visitor


Because this is an introductory article to software design patterns, I'm going to leave you with a few resources to get you started down the path. I'll be covering specific design patterns over a length of time, so make sure to check the "Related Articles" section at the bottom of this page, from time to time. Until then, take some time to read up on the Gang of Four.

No comments:

Post a Comment