Going Beyond Design Patterns

This was originally published August 2012

In our Design Patterns Thinking  course we quote Christopher Alexander’s Timeless Way of Building – the book that inspired the software development community to create design patterns. Most everyone familiar with design patterns is familiar with Alexander’s phrase “patterns are solutions to recurring problems in a context.” However, my favorite quote of Alexander is 4 pages from the end of his 549 page book –”At this final stage, the patterns are no longer important: the patterns have taught you to be receptive to what is real.”

For those new to patterns, these two quotes may seem contradictory, but to readers of his book and attendees at our course, the typical response is “yes, I already knew that.” Design patterns are solutions to a design problem in the way recipes are solutions to a “what do I want to eat?” problem. Learning design patterns as solutions to recurring problems in a context in order to be a great designer is like learning how to be a great chef by learning recipes. While useful to a degree, it is not very effective to become a master.

We need to remind ourselves that patterns are examples of solutions given a particular set of issues to be dealt with. The Gang of Four’s set of 23 patterns provides a meta-pattern that can teach us how to handle variations in a problem domain. Our Design Pattern Repository lists patterns by what they encapsulate. This is an extremely important insight. In both Agile and non-Agile teams, requirements will change – the biggest differences are: rate of change, size of change, and how we prepare our code for the change.

Most new requirements change in how a concept is to be implemented more as opposed to a totally new concept emerging. Code is often written as “this is the way it’ll work” and therefore is not well prepared for when a new, different way comes along. When we truly understand the thought process of patterns, they will provide us with a different way of looking at the world. I discussed this in my article Can Patterns Be Harmful? as well as my book Design Patterns Explained: A New Perspective on Object-Oriented Design. In other words, patterns don’t just provide us with good solutions, they can provide us with a thought process in which to achieve quality solutions to unique situations for which no current pattern exists.

The focus on patterns as solutions is unfortunate. The insistence that patterns are discovered, instead of created, obscures the fact that there is a thought process underneath these patterns. This thought process is worth discovering.  One aspect of this thought process is how to refactor code using the knowledge of patterns – something called “refactoring to patterns.” I introduced this concept in our first design patterns class in 1999 (as well as my aforementioned book). It provides a basis for refactoring quality code as needed using the thought process of patterns. You can learn more about this in the Refactor To The Open Closed chapter in our Essential Skills for the Agile Developer: A Guide to Better Programming and Design book. This is also discussed in the Avoid Over and Under Design chapter the same book. If you prefer webinars, watch Avoiding Over and Under Design in Agile Projects.

If you want to learn more, the best place is to take one of our Design Patterns classes. We currently have one scheduled in Seattle – Design Patterns for the Agile Developer, October 30- November 1. If you are in another city and have 4 or more folks interested, please contact Mike Shalloway (mike.shalloway@netobjectives.com) and we’ll see if we can schedule a course near you.

 

TDD and Design Patterns

Design patterns in software came from the work of the Gang of Four in the mid-1990’s. Similarly, TDD was first promoted around the same time in history as part of eXtreme Programming. Some have suggested that these two points of view stand in opposition to each other, saying

Design patterns are about up-front design, while TDD is about emerging design through the test-first process.

In truth, TDD and design patterns are highly synergistic. Understanding each of them contributes to your understanding of the other. Continue reading “TDD and Design Patterns”

Tests are Client Number 1

When a test precedes development, it essentially becomes the first “client” for the behavior being developed. This fact is helpful in several ways.

First, the interfaces TDD drives into the system are always client-focused. They are not implementation-focused because at the moment they are created there is no implementation yet. In their seminal book on Design Patterns, the Gang of Four recommended, among other things, that we “design to interfaces.” TDD promotes this in a fundamental way.

Also, the tests themselves provide a glimpse into the qualities of future clients. For example, Continue reading “Tests are Client Number 1”

“Good” Tests in TDD

As consultants, we are often asked to review the work of others. One of the things we review is the quality of the design of some part of the system. Is it cohesive, decoupled, non-redundant, encapsulated, open-closed, and so forth? Often the developers understand and agree that these qualities are important, but they are not certain they have achieved them adequately.

I often start like this, “I don’t know. Can you write a good test for it?”

I can ask this even before I look at their work because I know that bad designs are notoriously hard to test. It’s a great way to start an evaluation. Continue reading ““Good” Tests in TDD”

TDD and the Separation of Concerns

One aspect of strong design is that separation is created between the various concerns of the system. This adds clarity, promotes re-use, improves cohesion, and in general adds value to the work.

It can be difficult to know, however, if one has separated things sufficiently, or perhaps has overdone it. This is one area where TDD can help.

Example: An object with asynchronous behavior has, at minimum, two categories of concerns.

How Design Patterns Give Insights Into Process Patterns

Design patterns are often described as “solutions to recurring problems within a context.”But the real power of patterns is to see the forces that each pattern resolves. They should be used as a way to help analyze what’s needed to create a quality design. That is the goal.

Given a situation where, say, the Strategy Pattern was not quite present but its concepts could be used, no one who understood patterns would criticize the solution by saying ,“Well, that’s not a Strategy Pattern!” So why do we hear these sorts of critiques in the process world? Let’s think about it. Continue reading “How Design Patterns Give Insights Into Process Patterns”