Are you pattern happy ?

i kept this secret deep inside of me for a long time. but now i can’t stand any longer and so it must come out: yes … i admit … i was pattern happy ;o)

it startet soon after post-graduation at my first job as a consultant for a big it company. at that time i was half-baked with little experiance with respect to the design of software systems. but that should change! i wanted to be a good designer – a master designer! and deep inside of me i was afraid. afraid of producing bad design proposals. afraid that one could blame me for poorly designed software systems. and so i grabbed for every support that could help. at that time design patterns were a very hot topic. it looked like they should be the ultimate solution to all of my problems since it seems that those patterns conserved the wisdom and experiance of all those great developers – experiance that i could’nt exhibit at that time

the journey begins

and so i startet to study the gathered knowledge of the gang of four. i browsed the web. i bought books about patterns in java – volume 1 and 2 (and if there were volume 3 i had bought it, too), a book about patterns for J2EE development, architectural patterns, patterns in smalltalk (even i didn’t know anything about the language at that time) – in essence patterns patterns patterns in order to compensate my inexperiance.
i startet to speak in patterns. that sounded professional and colleagues seemed to be impressed. whenever a task was given to me, i first of all tried to apply some matching patterns in order to solve the problem – it payed off when i used those pattern stereotypes inside of my uml diagrams that we had to create for our customers. yes – i was on my way to a rocking hell of a designer …

what? me? pattern happy?

then – some day – i was meanwhile convident that a great knowledge of patterns means to be a good designer – i found another book about patterns that i had’nt heard of so far: ‘Refactoring to Patterns’ by Joshua Kerievsky.
it sounded (and still is) very good. it gave some considerably advices of how to apply refactorings in order to move your design to or towards well known patterns. that hit the spot for me! but wait – Joshua also talked about refactorings that moves away from patterns. i was puzzled! how could someone move voluntarily away from a pattern? then i read about ‘Patterns Happy’ for the first time and about the risk to over-engineer a design. could that be possible? could one over-engineer for a given problem? gentle doubt creeped in. i started to ruminate about the goal of design patterns and it hits me like a bolt from the blue: patterns aren’t the goal – patterns are at most an instrument.
but if patterns are only the instrument, what are the right goals then? i started to realize a reasonable answer as i continued to read. Joshua gave a great example where it was obvious that you may lose sight of simpler ways to solve a problem. in this example a pattern based solution was applied to a small problem that – all in all – was more complicated than it needed to be. yes, the solution was very flexible, should there be future requirements. but it wasn’t adequate for the given problem now and here. instead it introduced more complexity than needed so that the code wasn’t simple any more, harder to read and took longer to understand.

goals

have you noticed it? the goals? simple, comprehensible code that is easy to understand (and maintain). those are surely valuable goals! and in the majority of cases it’s a question of a trade off: upfront flexibility and a potential risk of a more complex code base on the one side and smaller, simpler, mostly better understandable code on the other.
and yes – as a pattern happy designer i ignored the deliberate decision for one side of those trade offs. i blindly followed the side of flexibility. not that it is the dark side, the easy side of the power per se. but i potentially was locked for the other side – i was blind for a perhaps more appropriate solution for a given problem space. yes – i was pattern happy!

how to recognize that you are pattern happy

following are some simple signs for an indication that you may be also pattern happy:

1. you cancel private events with friends because you preferably sit alone at home in your armchair and ‘invent’ some ‘patterns’. yes, that’s true. i heard of guys that are ‘searching’ for new patterns that they could proudly present to the pattern community.

2. ‘pattern matching’ almost works even at spare time.
‘oh – you mean that i’m registering myself as an observer at your bookstore and you’ll fire an event and give me a callback when the book arrives?
but why’s the book still so expensive? is it a singleton or do you apply a special selling strategy in my case? hm, my internal state changed to doubt – perhaps i should visit all other stores in town that will apply to customers like me and collect their prices …’ ;o)

3. you’ll use the ultimate ‘big pattern hammer’ even for the simplest tasks.
let me explain by a simple example. remember the fizzbuzz quiz? enumerate and print all numbers starting from 1 to 100. for all numbers that are divisible by three (without remainder) print ‘fizz’ instead of the number. for all numbers that are divisible by five print ‘buzz’. should the number be divisible by three and five, print ‘fizzbuzz’

here’s a simple solution in java:

public void printFizzBuzzNumbers( int start, int end ){
    boolean fizz, buzz;
    for( int i=start; i<=end; i++ ){
        if( fizz = ( i%3 == 0 ) == true ) System.out.print( "fizz" );
        if( fizz = ( i%5 == 0 ) == true ) System.out.print( "buzz" );
        if( !( fizz || buzz ) ) System.out.print( i );
        System.out.println();
    }
}

if you should have a solution like the following hinted one in mind, you may be in slight, hard pressed to explain difficulties for your next simple design job:

public void printFizzBuzzNumbers( int start, int end ){
    // of course a singleton
    SequenceFactory factory = SequenzeFactory.getFizzBuzzNumberInstance();

    // an internal iterator
    Sequence<FizzBuzzNumber> sequence = factory.sequenceFor( start, end ); 

    printNumbers( sequence ); 
}

public void printNumbers( Sequence sequence ){
    finally StringWriterStrategy writer = new NewLineDecoratorWriter( new ConsoleWriter() );

    sequence.each( new ItemHandler(){
        execOn( Number number ){
            // a FizzBuzzNumber knows when to write 'fizz' or 'buzz' or ...
            writer.write( number.toString() ); 
        }});  }
 

ok – i may be pattern happy – and now?

meet the local support group. if it doesn’t exist, found one and hope for like-minded people in your region.otherwise you’re in big trouble.
no – seriously now. following are some guidelines that might help to find back to the right balance:

1. choose your instruments deliberately – become clear about the context of the given problem space and the intended goals.
what are the most valuated quality criterias?
is it flexibility over all? is it extensibility or reusability in different contexts? or is it simplicity, easy readability or clarity?
what are the intented goals und directions?
avoidance of code duplication? simplifying the complicated? communication of intention?
in which context will the solution be used?
is it a part of a core module that may stay stable for a long time? or is it used within a ‘disposable’ solution (maybe a prototype) where the code isn’t the first benefit or of short relevance?
or is your surrounding work environment really agile, that management will give enough time for continous evaluation, continous refactoring and design evolution (avoiding the YAGNI syndrome)?

2. be rather pragmatic than dogmatic
this follows directly out of point one. don’t be locked for only one possible way of a solution.
Don’t blindly use patterns where a simpler solution is more appropriate.

3. don’t turn of your brain!
this guideline applies actually for all kinds of activities you perform. as you’ve heard on other prominent location – there is no silver bullet. even not in the area of designing software. you can’t turn of your brain and choose a pattern by reflex or by matching the forces of a given problem space. only the given goals and valued quality criterias will give the right direction. a solution that is perfectly right in one context might be completely over-engineered and inappropriate in another situation.

think!
maybe a pattern is the right choice.
maybe a simpler solution is the better choice.

Advertisements

6 Responses to “Are you pattern happy ?”

  1. Anonymous Says:

    Very good post…. save us from the overenthusiastic pattern people!

  2. Anonymous Says:

    I was very enthusiastic for patterns for quite a while, but was struck by another viewpoint when I read that a pattern is not a feature, it’s a bug in the language you’re using. If you have to do the same thing over and over, you should abstract it away and do it once.
    If your language won’t let you, your language is too weak.
    Also: what is rocket science in one language is straighforward in another, a pattern in another, infrastructure in another, and invisible in another. (Compare iteration in assembler, c, java, smalltalk, haskell.)

  3. Orban Botond Says:

    This is a very essential observation Anonymous.
    My favorite example:
    Java Developers must implement two interfaces and three classes in order to apply operations transparently on a data structure. The same can be implemented in javascript and ruby simply by calling the each method. Well… The famous visitor pattern.

  4. z » Are you pattern happy ? Says:

    […] Check it out! While looking through the blogosphere we stumbled on an interesting post today.Here’s a quick excerptit startet soon after post-graduation at my first job as a consultant for a big it company. at that time i was half-baked with little experiance with respect to the design of software systems. but that should change! i wanted to be a … […]

  5. Jacob Santos Says:

    I would rather you spend more time learning how to write. If I worked with you, then I’d be slamming your head on your desk every time I received an email that didn’t have complete sentences, capitalized letter at the start of a sentence.

    You might kick ass as a programmer, but I’d rather work with someone who can write at least somewhat competently. Trying to read your entire post was akin to torture. The only reason I read passed the first paragraph was the subject.

    So in summary, good post that was written poorly.

  6. Mario Gleichmann Says:

    Jacob,

    thank you very much for your kind and friendly words :o)

    You may take a look at some newer posts – i started to use capitalized letters due to some advices from others.

    Thank you very much for showing me in this clear way, that a text should be convenient to read, not to write.

    Please excuse this experimental style – as English is not my first language (and thanks to your additional motivation), i will even try harder to get better in your language in order to meet your demands ;o)

    Greetings

    Mario


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: