For Any Pattern: Check to See if It Creates a More Needs-Oriented Interface

Design patterns thinking tells us to design to interfaces. This has nothing to do with the keyword interface that is available in a lot of languages. It's about the English word "interface".

You know... the "I" in "GUI" or "API".

With few exceptions, a needs-oriented interface represents a better contract for a class than a capabilities-oriented interface would. The better-ness of this contract manifests in two ways:

1. The coupling that forms will likely be long-lived and resilient to implementation-changes.
2. It provides more context and drives better internal design decisions.

If you are considering whether or not a design pattern applies, try asking yourself if introducing the pattern will make the interfaces involved more about what should be accomplished or more about what should be done.

If the interfaces become more about what should be accomplished, that's a vote in favor.

If the interfaces trend toward a more imperative nature, you might want to reconsider.

For Any Pattern: "Does This Allow More Objects to Each Deal with Fewer Things?"

One of the principles of design patterns thinking is favoring delegation between objects over inheritance from one class to another.

I think we can actually expend that if we want to:

Favor delegation between objects over the same object doing two things.

Remember, when you inherit you end up with one object even though you wrote two classes. So the way I just wrote it still works for inheritance but it also works for, say, lumping everything together into a giant algorithm.

Note: Not more classes. More objects.

If you are considering a design pattern for your codebase and you're not certain if it applies, ask yourself this:

"Does this allow more objects to each deal with fewer things?"

If so, you may be headed in the right direction. If not, maybe consider a different approach.

For Any Pattern: "Does This Make Something Less Aware of a Kind of Variation?"

If you have alternatives - different kinds of things that can be used to replace one another or, sometimes combined with one another - then you have variation.

Design patterns thinking tells us that we should encapsulate variation. That's the kind of thing that is obvious once you already understand it (the hallmark of a good idea) but turning the advice into action can be challenging for people at first.

The immediate goal isn't really to make code less aware of the fact that there is variation so much as making your code so it doesn't need to change when you add or subtract a variant.

So, it's not that we're trying to hide variation altogether. We just want to minimize its impact on most of the code. We are seeking to lessen awareness, not eliminate it altogether.

If you are considering a design pattern for your system, and you aren't really sure if it's the right way to go, ask yourself this:

"Does this make something less aware of a kind of variation?"

Or...

"Does this make something less aware of the variants in a kind of variation?"

If the answer is "no", you aren't attending to the fundamental value-proposition of design patterns thinking and there's a good chance you should be considering another path.

For Any Pattern: "Does This Help Me Couple to an Higher-Level Abstraction?"

One of the things that design patterns thinking is supposed to help you do is elevate the level of abstraction in your code. That doesn't just mean "write more interfaces" or "use ore abstract classes/protocols".

What it means is try to move the points of coupling away from the metal. The more a coupling point is about implementation details, the less useful it is and the shorter is helpful life will be. That is especially true an high-traffic interface but, really, it's true for the surface area of any piece of code.

So, if you are considering a design pattern and aren't quite sure if it applies to your situation, ask yourself this question:

"Does this help me couple to an higher-level abstraction?"

If applying the design pattern will make the interfaces (not the keyword interface, the English word "interface") a little more about "what" and a little less about "how", you might be on to something. If it cuts the other way, you may want to reconsider.

Design Patterns Questions

Like code qualities, I'm going to start sharing questions you can ask yourself to help sort through which design pattern applies where.

As I add questions to the set, I expect it to grow into a checklist someone can use to evaluate whether the pattern they are considering is the right one for their situation.

I'm not expecting to create a perfect result every time. I'm happy with better results some of the time.

There will be two categories of question: general and specific.

General questions apply to every pattern. For instance "What variation does this let me add without changing any existing code?" applies regardless of what pattern you are considering.

Specific questions apply to one pattern or a small group of patterns. For instance "Do I need to decouple when something happens from when the decision is made that it should happen?" applies primarily to the Command pattern.

The label for this post will also be on all such questions.