He's at it Again

(note: this is a continuation of a story that starts here)

Macrocosmic Code Qualities

As I've mentioned before. I think all software work is design work. I also have a relatively context-insensitive definition of code quality.

The code qualities to which I (and many) subscribe can apply at any level of design.

If you're writing a method, you can ask yourself any of the following...

• "How strongly-related are these instructions?"
• "How will I know when this is done?"
• "How easily will it be for my future-self to comprehend this?"

The same qualities translate into class-level design as different questions...

• "How strongly-related are the members of this class?"
• "How will I know that this class works as intended?"
• "How easily can I understand how this class fits into the larger design?"

The same principles apply all the way up to the very largest scale of software design and all the way down to the lowest-level detail.

This is one of the things that is great about these code qualities. They are general rules that are aligned with effects.

Cohesion matters because it defends against a certain kind of coupling, makes testing easier, and makes code easier to understand. It matters the same amount and for the same reasons at any scale.

There's something aesthetically pleasing about that.

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.

Cutting the Issue to Its Core