Reading on Design Patterns

As with so many other things in software development, usage of design patterns a hotly contested topic - to use or not to use is the question. My position is that we should know them and we should learn them. We should have the knowledge and the choice, if the need arises, to apply the right design patterns.

Learning about design patterns was one of the pivotal moments of my career as software developer. I was able to build better software since design patterns gave me blueprints to address large and complex requirements in structured ways.

My first exposure to a design pattern was ASP.Net MVC. The out-of-the-box structure gave a young developer like myself structure to build the requirements we were working on. Of course, this meant that there was a lot of "magic" I wasn't aware of. To help alleviate my fear of not understanding this "magic", I picked up Head First Design Patterns from my university's library; it was a bright and fun way to lay the foundations on which I could build. I recommend this as a first reading on the topic to my mentees and junior developers.

Being an engineer by study, I had to find myself a serious reading. I came to find Elements of Reusable Object-Oriented Software. This is the book I have in my bookshelf. The title of the book, its contents, its breadth and depth makes it a book of constant study for me. In it, from Christopher Alexender when talking about building, is a succinct and poignant description of what design patterns are:

Each pattern describes a problem that occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice. - Christopher Alexander

When I had moved on to building games with Microsoft XNA, the seminal article that helped me grasp and apply design patterns to game development was Evolve Your Hierarchy. While short, the article touched on some key points: discovering the pertinent patterns, communicating and building consensus on the patterns with a team and the approaches to implementing them in existing codebases.

Game Programming Patterns is an evergreen book that's also in my bookshelf. Its title can be quite misleading, a fact that the author also admits. I've found myself referring to this book while building applications across various different domains.

The Twelve-Factor App is another such resource that is applicable when building applications, specifically as a service, in any domain.

While I may refer to my bookshelf when building an application, I will always start with the articles on application architecture at martinfolwer.com. The articles always give me answers to the business and product value that I am looking for as well as tangible approaches to implementing the offered solutions. The other resource I often turn to is Refactoring Guru. My team and I often refer to it to discuss and review both theoretical details and implementation samples.

Design patterns, of course, can be applied across the many aspects of application development and there's an awesome list of resources for doing so. As a developer though, I have tried to have the understanding and knowledge to decide when it's best not to.

[Disclosure: This post contains affiliate links.]