Pattern Encoding (MyDE)

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.1

When experimenting with Kent’s technique, I was struck by some powerful positive side-effects.  Most importantly, as a professional with a vague ‘pattern palette‘ — further maturity demanded a set of cohesive pattern names.

Pattern Palette

While working through the approach learning occurred:

  • Patterns expressed with a single source class are a useful granularity for a Palette.
  • Vibrant applications may emerge from a minimal Palette by an artist (craftsman) with deep understanding of color combinations (that is pattern usage).
  • Some palette patterns correlate to application architecture layering and some are layer ubiquitous.
  • A core Pattern Palette, serving as a starting-point, is adoptable and/or extendable by a unique application project team.

After nearly three decades of writing code with informal emerged patterns, the discipline of a clearly articulated palette was ecstatically enabling; this was the best thing since TDD!  My creativity was invigorated by an ability to “program faster with fewer distracting thoughts”1.  Now… how to encourage an enterprise with hundreds of loosely-coupled Java developers on five continents supporting thousands of applications to experience the joy.  :-)

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 using a Pattern Encoded suffix (within a class name) might encourage the Palette approach for creative design?

… And another positive side-effect might occur… perhaps readers of the code would have a clearer picture of the design held in the author’s head by looking at the class name?

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 useful practice.  Here are two example names:

  • 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 25 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 emergence 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 JpcBaseBF() {
        JpcCodingConventionUS.checkClassSuffix(this.getClass(), “BF”);

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?

Revised: 9/2013

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… why shouldn’t I?


  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.