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 and Code Qualities

A friend of mine recently intimated that we don't need design patterns because all the principles and patterns can be derived from code qualities.

It's true. Patterns can be derived from the principles of code qualities...the same way aerodynamics can be derived from quantum mechanics.

When All You Have Is an Hammer...

A lot of the time, when I come into an organization and look through their code, it's really easy to tell when one of the more gung-ho developers just learned their first design pattern.

Suddenly, there's an area of the code-base where everything looks like the Visitor pattern diagram or the Observer pattern drawing.

It's easy to fall into this kind of trap. Not everyone does but I haven't done the science to figure out what, if any, extrinsic factors affect whether or not this happens. I doubt anyone has.

I didn't have it happen and it's really easy to trace why. I had already "invented" the design patterns long before I was exposed to the book. Before the book was even written, really. My difficulty with patterns was "Why should I use these?" not "How can I make these useful?" I'm sure plenty of developers my age had that same experience.

I know a couple of people who were introduced to design patterns on my watch and who didn't seem to go through the "everything is this pattern I just learned" phase. Yet, I know a whole lot of people who went through that phase, regardless of who introduced them to patterns.

It's probably okay.

It's more important to find your way out of it than it is to avoid getting into it.

There is one defense I can imagine. I have no proof it will work but it probably can't hurt. Whenever you realize you are trying to bend a problem to fit a pattern, remind yourself that you should be finding the pattern that fits the problem, instead.

Design Patterns Live in Solutions

This week, I've been talking about where Design Patterns live and where they don't.

I have a suggested model and I didn't come up with it alone. It was an accumulation of knowledge from old work and a collaboration with Eran Pe'er of DevCraft.

First, I'm going to lay out some information.

Think about all the ways a Design Pattern can impact your life as a developer...

A Design Pattern can be a starting point for existing code, the goal design for new code, the destination for a sequence of refactoring moves, or any combination thereof. It can be an area of study for someone attempting to advance their skills, a collection point for knowledge about how to address certain kinds of problems, and a phrase in a high-bandwidth conversation between developers.

There are more advantages but these six are really, really important.

All of those things are either directly or indirectly about solving problems. It stands to reason that design Patterns are tools we use in solving problems. They are far from the only part of solving a problem, they represent a critical aspect nevertheless.

To me, that's where Design Patterns live: in the act of solving a problem or helping someone else do the same.

I like positioning Patterns as solution elements. It connects them to problems the way they should be connected to problems. It connects them to implementations the way they should be connected to implementations. It gives us a language to describe, refine and expand them appropriately.

Is it perfect for everyone, always? Probably not.

Is it good enough for me, now? You bet it is.

Design Patterns Are Indicated by Problems

If patterns don't live in code, drawings, or any implementation artifacts, then where must they live.

Some have suggested that they live in problems. There is substantial evidence to support this claim.

I'm not sure if I'm totally on board with the idea that a design pattern lives in a problem but I will definitely agree that the problem you are addressing is one of the primary factors influencing which pattern applies.

In other words: problems indicate patterns.

Design Patterns Don't Live in the Code

In my previous post, I wrote that design patterns don't live in the drawings. You can't just replicate a picture someone drew a bunch of times and get a good design.

A natural next conclusion is that they must live in the code. This is also not the case.

Design Patterns Aren't the Drawings

An easy, and very forgivable mistake is to think that the drawings in the original book, Design Patterns, are the essence of the patterns.

One reason someone might make the mistake is that the drawings proliferate like dandelions.

Fundamental Tenets of Design Patterns Thinking

There are four basic principles of deep design thinking. These are all paraphrased to make them easier to digest in 2018.

• Start with contracts and drive implementations to serve needs.
• Encapsulate variation so you need only attend to it in the fewest places possible.
• Couple to the highest abstractions possible.
• Delegate between objects rather than inheriting between classes.

These principles underlie all the design patterns wherever they apply.

One could write a book on these four principles. In fact, a lot of people have.

I'm going to dig into each of these more deeply in subsequent posts.

Vestigial Inheritance

Favoring object-delegation over inheritance as a way of sharing traits between classes is a field-proven technique. So many people "invent" that technique while they are learning that it's hard to trace it to its true origin.

Certainly, the Gang of Four did a lot to popularize the notion.

Yet, there are little places where people still tend to trip and fall back into inheritance as a way of sharing commonalities.

Object-Oriented Performance

Long ago, in a land now distant to me, I worked for a very successful company.

They were the kind of company that wasn't successful because they were good at software development. They were good at something else and they had to do some software development to make that offering in the modern era.

I was brought into one team by a friend of mine in order to change their thinking. Years later, I heard they still reference me as the reason why they write tests first.

One Way Design Patterns Help

Design patterns can help a team by facilitating high-value communication about design.