The genesis for this notion of Pattern Encoding belongs with a reading of Kent Beck’s book entitled Implementation Patterns.  Kent describes how he disciplined himself to mature in his use of patterns by writing down the pattern description before coding.¹

When experimenting with Kent’s technique within my own context, I was struck by some powerful positive side-effects.  Most importantly, as a professional with my own ‘pattern palette’ I needed to start with a set of cohesive pattern names!

As I worked my way through the approach additional learning occurred:

• That a pattern easily expressed with a single class of source code is the right granularity for a palette.  (Although, I’m also experimenting with a limited Method Pattern Palette.)
• That a vibrant application may emerge from a minimal Class Palette by an artist with deep understanding of core color combinations (that is patterns).
• That some patterns correlate to application architecture partitioning and some are layer ubiquitous.
• That a core Pattern Palette, serving as a starting-point, is adoptable and/or extendable by a unique application project team.

After a quarter-century of writing code without a clearly defined palette I was ecstatic; this was the best thing since TDD!  My creativity was invigorated by this ability to “program faster with fewer distracting thoughts”¹.  Now… how to get 900+ Java developers on four continents supporting hundreds of applications to experience the joy.    [Veiled reference to a large automotive headquartered in Dearborn, MI.]

After considering standing on a tall building and shouting loudly… rejected because my voice is not that strong… and then considering authoring a set of YouTube videos…  rejected because my voice is not that compelling…  perhaps expressing a Pattern Encoded suffix (within a class name) might encourage pattern enabled design?

… And another positive side-effect might occur… perhaps readers of the code would have a clearer picture of the design thought the author held in their head when the class was initially named (or the name was subsequently refactored)?

There are some wonderful adages in the book “Clean Code – A Handbook of Agile Software Craftsmanship” (Robert C. Martin).  These quotes come from Chapter 2 on Meaningful Names written by Tim Ottinger:

“We have enough encodings to deal with without adding more to our burden.  Encoding type or scope information into names simply adds an extra burden of deciphering.” (p. 23)

“One difference between a smart programmer and a professional programmer is that the professional understands that clarity is king.   Professionals use their powers for good and write code that others can understand.”  (p. 25)

“Remember that the people who read your code will be programmers.  So go ahead and use computer science terms, algorithm names, pattern names, math terms and so forth. … The name AccountVisitor means a great deal to a programmer who is familiar with the Visitor pattern.”  (p. 27)

A casual glance at the above statements might leave one with the impression they are inconsistent with the notion of Pattern Encoding.  However, my opinion is that   using encoding for “type or scope information” [underlining added], an unwise practice, is distinct from using encoding for pattern identification – a potentially wise practice.  Here are two example names (linked to class diagrams):

• BookingDE
• ManageBookingBF

The BookingDE name is parsed into a noun-oriented domain name (Booking) plus the encoding for the Domain Entity pattern.  The ManageBookingBF name is parsed into a use case function (Manage Booking) followed by the encoding (Business Facade).  Upper-case encoding provides visual differentiation.

Experience with this approach has revealed that 15 encodable patterns is probably too few for a palette with effective cohesion… and more than 30 is probably too many as they become a “burden” (using Tim’s word) for instantaneous recall.

So one question comes into focus… does a limited amount of Pattern Encoding necessarily become a burden?

And a second question surfaces… can an author’s powerful transformative habit also assist the reader?

And perhaps the most important question… does a shared palette between author and reader promote understanding?

At this time, I can only answer these questions in the context of a single Successful Large Enterprise;  within that context the use of Pattern Encoding was surprisingly well-received by both authors and readers.  We particularly anticipated significant push-back when including a Coding Convention Exception in base classes using the following semantic:

/**
 * Constructor
*/
public SjcBaseBF() {
    super();
        SjcCodingConventionUtil.checkClassSuffix(this.getClass(), “BF”);
     return;
    }

Surprisingly, there was mild appreciation for the coding convention exception as a tactic to assist others on the team to follow the suffix convention.  Said another way, there was little confidence that distributed team members would align with a “Coding Convention” document absent mechanical detection of a mutually agreed upon ‘violation’.  Said a third way, the fact that detection was in place seemed to cause greater acceptance for Pattern Encoding.

What remains unmeasured is whether Pattern Encoding, by encouraging the use of a cohesive pattern palette, fundamentally results in ‘better’ design?

_Marvin
Originated: 8/2012

P.S. A friend suggested that this approach was a good thing for ”below average programmers”.  My response was in the form of a question - If Kent found value in having a protocol to help condition his mind… shouldn’t I?

References

1. Kent Beck, Implementation Patterns, p. 20.

Once a set of implementation patterns has become habitual, I program faster and with fewer distracting thoughts.  When I began writing my first set of implementation patterns (1996) I thought I was a proficient programmer.  To encourage myself to focus on patterns, I refused to type a character of code unless I had first written down the pattern I was following.  It was frustrating, like I was coding with my fingers glued together.  For the first week every minute of coding was preceded by an hour of writing.  The second week I found I had most of the basic patterns in place and most of the time I was following existing patterns.  By the third week I was coding much faster than I had before, because I had carefully looked at my own style and I wasn’t nagged by doubts.