Design Patterns: Genius or Overengineered?

When we talk about industry-wide design patterns, however, people are generally referring to patterns found in the seminal book, Design Patterns: Elements of Reusable Object-Oriented Software. First published in 1994, this book has greatly influenced design thinking for many developers. It has sold over half a million copies and been translated into 13 languages. The authors have become known as the Gang of Four for their influence on software development, and you’ll often hear references to the GoF book or GoF patterns when talking about abstract software design principles.

Design patterns have a lot of benefits for standardization, scalability, and fundamental code structure. However, they can become obtrusive and bulky when used unnecessarily, crowding the application’s core code with a lot of layers of abstraction. In this article, we’ll look at the pros and cons of design patterns, why you should still learn them, and tips for deploying them thoughtfully.

You’re Not the First Developer

When you run up against a problem in your code, it may feel like you’re in uncharted waters, but it’s helpful to remember that people have been coding computers since the 1940s. It’s likely someone has run into your problem before (or at least something similar). You can draw on the wisdom of past generations of coders by using design patterns effectively.

After all, there’s no need to reinvent the wheel here. Most common tasks in software development have established best practices or options for how to resolve the issue at hand. You can save time and mental energy by learning and applying common code patterns in your programming.

Using these patterns often has ancillary benefits as well. They may be more efficient or scale better in the future. When you use an established pattern, you can be sure you’re writing code in a way that other developers have thought about and optimized. As we’ll see shortly, context plays an important role, though. Sometimes code patterns are well-optimized for the task at hand. Other times, they create unnecessary bulk.

Communicating with Other Devs

Another key benefit of using code patterns is it becomes easier to talk to other devs about what your code is doing. You now have labels and a vocabulary to describe complex, abstract information flows. Telling a fellow developer that you used a factory method pattern to create that object, for example, allows you to both be on the same page with much less confusion.

The same goes for developers that you’ll never talk to in person. When you leave a company or project team, someone else will have to maintain the code you wrote. Including information about the design patterns you used in the comments and/or project docs makes the job much easier for the guy who came after you. Just make sure to think about and clearly articulate why you’re using a given pattern as well. Don’t use a pattern for pattern’s sake only. Be thoughtful about how you deploy patterns in the real world.

Less Code Is Usually Better

Part of being thoughtful is asking, “Do I really need this code?” While code that follows design patterns is often prettier or more elegant, that doesn’t necessarily make it better. In most cases, deploying a design pattern adds more lines of code to your codebase. If so, then you should have a good reason for doing it that way.

This isn’t necessarily a fault of the pattern. Code patterns are long because they are designed to work in a variety of contexts. However, when it comes to the context of your specific project, implementing a long design pattern might not make sense. Doing so can add layers of abstraction that make maintenance or future additions more difficult. Nothing is more frustrating than taking several hours to add a new field to a UI/database/data layer because of design patterns, for example, when a simpler structure would make adding a new field only take 30 minutes.

Coding for Hypotheticals

One big reason why developers get sucked into overusing design patterns is constantly thinking “what if?” In the future, the software you write could undergo any number of changes. While some design patterns might make those future changes easier, writing the code that way from the get-go is likely to take longer. Coding for hypotheticals is how a project that should take two weeks expands to fill two months because the dev is attempting to address every potential future change.

Notwithstanding, there is a case to be made for intuition and good developer judgment here. If there are changes that are highly likely in the future, then planning ahead for those changes makes sense. However, writing code for every possibility is a good way to bloat the codebase and expend a lot of extra time and effort.

Know Them, But Don’t Rely on Them

There’s definitely a place for design patterns in software development. They are useful, tested, and standardized ways of thinking about code. The lesson here is not to apply them blindly. Consider context, need, and the impact using a pattern has on initial development time and maintenance down the road.

A good analogy is a piano player practicing scales. A good piano player needs to know all the scales forwards and backwards, but they would never show up to a concert and play a scale as their piece. Instead, the scales are an important part of the music and how it’s structured, but the pianist deploys the key concepts and individual notes from the scales to make great music.

In the same way, a good developer should know and practice design patterns. They should be an integral part of training and a great vocabulary between colleagues. However, the patterns should be deployed carefully and only when needed in real world applications. Knowing design patterns well makes it easy to spot when they’ll be useful and when they’ll only clutter the code.