The problem is as important as the solution!

If you are a decent developer, there is a good chance that you have read about design patterns, probably from famous books like “Design Patterns: Elements of Reusable Object-Oriented Software” and “Patterns of Enterprise Application Architecture”.

The first book, best known as Gang of Four, suggested a template for design patterns which has been used by many authors since. This template suggests what sections must be included in the definition of a design pattern. This sections can be categorised into 3 groups, sections that define some names for the pattern, sections that try to describe the problem, and sections that try to define the solution. Usually a big chunk of the content tries to describe the solution, hence most of the developers pay more attention to that part. Through my first post in my new weblog, I am going to argue that understanding the other two groups are as important as the solution, if not more important.

My first argument is that, a solution does not exist if there is no problem. So the logical flow of thinking must be like, identifying the problem, and then searching for a solution for the problem. Surely enough when using design patterns becomes a routine activity, these two steps will be merged together. However before that, a newbie can mistakenly use a wrong solution for a problem.

Think about Singleton pattern. The problem that Singleton addresses is to guarantee that only one instance of an object exists throughout the whole system. The solution is to make constructor of the object private, and then provide a public static method to access private constructor. Then user will be able to limit creation of instances of that object through that static method.

class Singleton
{
	private Singleton()
	{
	}

	private static Singleton instance;
	public static Singleton Instance
	{
		get
		{
		    if (instance != null)
		        return instance;

		    lock (typeof(Singleton))
		    {
		        if(instance == null)
                    instance = new Singleton();
		        return instance;
		    }
		}
	}
}

Unfortunately if someone does not know the problem that Singleton pattern tries to solve, s/he might use this elegant solution in a wrong place. Singleton pattern can wrongly be used as a way to make something accessible through the whole application. Using Singleton in such a way is like defining a global variable which is not just misusing something elegant, it even causes tight coupling further down in life of the software.

Apart from having a proven solution for a reoccurring problem, design patterns have other advantages too. For example, design pattern name can ease developers communications while exchanging their ideas. However using the name of a design pattern without knowing the problem that it addresses is somehow misleading.

As an example, consider that there is an abstract Sensor class, and there are two concrete classes, TemperatureSensor, and PressureSensor that inherit from it. These sensors can be initialised to work with Imperial or Metric measuring systems. To implement functionality, one can create an interface called ISensorInitialiser, and then create two concrete classes to implement that interface, called ImperialInitialiser and MetricInitialiser. Then ISensorInitialiser should be injected to the Sensor class. This way coupling and code duplication will be reduced to some extent.

PSuml

The above UML diagram is similar to both Strategy and Bridge Patterns, but the similarity stops there. These two patterns address two very different problems. Strategy pattern is a Behavioural pattern that tries to simplify changing behaviour of an object in runtime, while Bridge pattern is a Structural pattern that “decouple an abstraction from its implementation so that the two can vary independently”. Naming the above solution as Strategy implies that we wanted to solve something dynamically during the run time, which is quite misleading and confusing, while describing it as Bridge pattern is more accurate and informative.

2 Responses so far...

  1. […] RSS ← The problem is as important as the solution! […]

  2. […] I lost my fate on this already, developers don’t know many design patterns, I accepted that long time ago. Asking candidates what is this pattern and what is that pattern usually doesn’t work, since everyone just know a few patterns. I usually let the candidate to pick the design pattern he wants to describe, as long as it is not singleton. But the interesting part of their explanation is the way that they describe the problem that the design pattern solves. Because I believe the problem is as important as the solution. […]

Comments

Leave a Reply

Your email address will not be published. Required fields are marked *