Follow treslines by email clicking Here!

Saturday, December 7, 2013

How to identify design pattern before coding?

Hi there!

In this post we will learn how to identify design pattern before coding! Isn't it exciting? As you probabilly know, i'm addicted to design patterns. I've read a lot of good books and probabilly as you, my biggest problem was always the identification of cases/scenarios in which i could use them.

There are great books out there, but none of them explains in a simple way, how to identify it. Most of them says: "It depends on the usecase or it depends on the dev's expirience" In fact the expirience (years that you have been working on the software business) may help you identifying the right patterns to be used in some default scenarios, but can't we learn it a little bit faster? Do we have to wait years to get it done right?

Motivated by those questions, i've been trying to identify the patterns by the last mobile project i made. I was very surprised how simple it can be and how much better understandable, extensible and readable my end project was. All you need to do is to sketch it first. Really!!! That's all. Don't worry, we will see the whole process step by step. :-)

The Patterns

In this tutorial we will learn how i was able to identify a bunch of patterns before starting coding (Please note: In this tutorial i will not explain why a specific pattern is good or not. I will assume you know already design pattern and are interested in see how/when to apply it) In my project i was able to identify the following patterns:

  • Command Pattern
  • State Pattern
  • Adapter Pattern
  • Null Object Pattern
  • Singleton Pattern
  • Observer Pattern (Listeners)
  • Template Method Pattern

The Challange

Ok, let's get to an apparently simple, but real project. Imagine you have the following challange:

You have 4 buttons on a toolbar on the bottom of your application. Every button starts its own animation  when it is tapped (let's say it is moved upward to show its activity) and after its animation is done, a second animation starts. (let's say a column is slided out showing icons on it). Can you imagine it? something like this:


The requirements

Ok, let's move on. Here are futher requirements:
  • Every animation has to be synchronized which means, if an animation is running, none of the other animations can be started, till it ends. 
  • After every transition (animation) we should have the possibility of excuting some actions if we need. (let's say play a sound or execute a desired action)
  • Every button must be locked to each other. This means, if i press and hold one button, i can't fire another action by pressing anoter button.
  • If we touch the screen and an animation is showing already, this animation will slide back and a defined dafault button will be selected. (will be moved a little bit upward)

How can i identify the patterns now?

Know that we have sketched the scenarios and have listed the requirements, how can we identify proper pattern to use in this case?

Well, what i have done was to simple imagine the five buttons as a TV-Remote control and the animations as transition states on my screen. Doing that way it was almost impossible to not see the patterns. So i thought i had commands to start the animations (Command Pattern) and i thought i had states to represent any animation's transition. (State Pattern) - The key to this was the sketch i made. Imagine: Without it, it would be almost impossible to see it.

We should give the possibility to fire actions between states. And because this should be only possibilities, i can imagine scenarios in which there will be no actions also possible right? And here they are: NullState, NullAction and NullCommand. (Null Object Pattern)

Ok let's think further. As a requirement we must ensure singularity to any button. So i automatically see the picture of a lock, because there should be only one way to start actions. In that case we need a global accessible but unique flag to control that. (Synchronized Singleton Pattern)

And last but not least, as we will be dealing with a lot of action listeners and because of the button's synchronization, it would be necessary to implement a lot of individual Listeners for every button. If we do that way, we would end up with a bunch of duplicated code lines. For this reason we should implement an adapter of the TouchListener in which we place the lock logic in central unique place (Template Method Pattern), making it available for all buttons in the aplication. (Adapter Pattern). So i ended up with a simple but very usefull class diagram like that bellow which i used to define the app's architecture (structural part of it):

initial class diagram


In my opinion at least two things are indispensable in the process of figuring out what design pattern to apply:
  • a sketch 
  • as many requirements as available

Share your expirience

If you know other simple, practical ways on how to find out which design pattern to use, please feel free to contact me and share your thoughts.  It would be great to se the usage of other pattern in practise. (real projects) like i did. That's all. hope you like it.


  1. This is not how you design or write a program.
    A pattern is just a reoccurring way of doing something. When you design and write a program, you do it to solve the task as simply as possible. While doing that you will frequently use standard patterns, but the patterns are incidental, they will be there when the program is finished and you may have thought along the way "i'll do that with a singleton because..." or "i'll make this accept command objects so i can do..." but at no point are you thinking "what standard pattern can i use to solve this problem ?". Instead you are thinking thinking things like "what is the best way to do this so that later i can do X..." and things like that. You certainly do not come up with a list of patterns you are going to use in advance that's a total waste of time.

    1. Hi there! Although i respect your opinion, i do not share it. In fact experienced programmers would never use, for example, a state pattern for just 2 or less states or implement commands for just one thing if they know it before. But that's exactly the point here. As you said yourself, pattern are standards to solve common problems in the most simple way. But how can we know it, if we do not have a plan (Sketch and Requirements). I strongly agree with you, when you say we should solve things as simple as possible, but we can only see it, if we think about it first before start.

      Further i think that simplicity has nothing to do with writing code as short as possible. Let's intentionally exaggerate and say two lines of code, but no one is able to read it, understand it or even maintain it. Simplicity is when something complicated is made simple or in a standard way(using proven good patterns when appropriate) in our profissional context.

      Unexpirienced programmers may say something is solved in a complicated way, because they do not understand the things yet. An expirienced programmer on the other hand may fill the eyes of water and praises the creator of the code, because he sees simplicity in the creation of things, in the expression of the code, in the maintenance, in the form of testing and so on.

      Let's put it in another light to visualize it: When we build a house, we try to make it as simple as possible, because it costs less or because we want to be ready faster. While building it, we apply proven technology and good standards. Not because we could not make it easier/simplier, but because we know that it is better that way in long term.

      if an electrician has to twist one screw into a piece of wood, he has a toolbox, in which he can decide whether he twists it by hand or with a cordless screwdriver. Although the second option means more work, most of them choose the second one, because they know it, it will be more efficient.

      I know a lot of programmers with many years of expirience with degrees from head to foot with great toolboxes, but they never use it. they nerver share their expirience. They prefer to program everything from scratch ignoring any kind of proven knowlege, good practises and so on. I saw classes that when printed out, it was as long as 20 A4-Pages with a bunch of if/else statements, states in it... oh my god I get dizzy just by remembering it :)

      anyway... I think it is worth to think and reflect about it before starting it and if it is already appropriate to resolve things with proven standards, we should try to do it so making usage of the "cordless screwdrivers" we have.