How to Choose a Design Pattern That Fits


by Joshua Hayes - Date: 2007-01-28 - Word Count: 941 Share This!

As a pre-cursor to design patterns in the previous article in this series I looked at common signs to over engineering your design by forcing a design pattern that doesn't fit. One important point I made was not starting with a design pattern and opting to refactor to one when you know it's necessary. Not over complicating your design with the noise of trying to fit a pattern into it before you know your design really requires one. If you have taken this approach it is at this point that your design has had some time to incubate on its own; stand, or crumble under its own supports.

In the case of crumbling supports you have identified a hole in your design. So what do you do with any hole? Search for the right size shape to plug it! Here's how.

Describe the hole your design pattern will fill

What type of hole is it that sits in your design? Since you are looking for a design pattern to fill the hole describe the problem as it relates to the three types of design patterns; creational, structural or behavioral. The goal here is to identify and narrow down the list of possible design patterns. So, is your problem a creational one? A Structural one? or a behavioral one? Once you have identified the type you have narrowed the list of options by two thirds.

How to identify the problem

Here are some tips on determining what type of problem you have.

Creational - If you are trying to separate the process of object construction and object use. Typically patterns like the Singleton, Factory, Abstract Factory and Builder Structural - If you are trying to interface to a sub-system, connect to an interface your system doesn't support or provide a flexible storage structure for adding and manipulating objects. Adapters, Bridges, Composites and Façade's are good examples Behavioral - If the primary concern is how you access objects, perform operations on them and otherwise interact with them consider patterns like the Command, Iterator, Observer, Strategy and Visitor

It should be noted that the list above is far from exhaustive. Just an example of what you might be looking for.

Determine your primary intention

Once you have worked out what type of pattern you are looking for you need to delve into your design a little further and decide what your primary intention is if that hole were to be filled. Here's an example I encountered recently:

I was pulling out a large amount of information from tables in a database and ultimately wanted to convert this information to xml, keeping any hierarchical information that was present in the database in the form of relationships. These hierarchies would then be used to define the level of nesting in the xml structure.

The tables retrieved would not always be the same and the xml structure would have to reflect this. Having ruled out using a persistence framework like hibernate or ibatis knowing that I could implement a much lighter solution, I then proceeded to create simple mapping files for the tables I was pulling out. This is where I found my hole. How do I structure and store this information in a manner that will reflect the final xml structure? To cut a long story short, the database tables I modeled as hashtables and used the Composite pattern to create the structure of composite components I was looking for.

In the aforementioned example the intention was to structure and model the table representations in a flexible hierarchical structure. The composite pattern provided a flexible means of nesting tables within each other thus preserving this structure.

Match your intention with that of a design pattern

Now that you have worked out the category your problem exists in and you have identified the principle problem you are trying to address you can begin exploring for a pattern that is designed to match the intention you are trying to fill. Most design patterns books describe patterns in this way; it then simply becomes a task of matching your intention with that of a pattern.

If you have identified your intention correctly and cannot find a pattern to match, don't fret. Your hole just may not be pluggable by a design pattern. Design patterns address problems that occur over and over again and provide a solution to the core problem so that this solution might be replicated over and over. It may be the case that your hole is not one of these problems that occurs over and over again and thus does not have a repeatable solution. It may just be an oddly shaped hole!

In summary, let your design stand on its own for a while first and see if there are any glaring spots in your design that are asking for further scrutiny. Describe the type of hole or gap in your design with respect to the three common design pattern types; creational, structural and behavioral. Once you know the type, state your intention as if it were to be filled and match it with the intention of a pattern in this category. In other words, don't choose the design pattern. Let it choose your design. The more familiar you are with the various design patterns and the more situations you have used them in the quicker you will become at spotting them in future designs.

This was meant to serve as a guideline to identifying patterns to fit design problems when you have discovered a pattern may be useful. It is just that, a guideline. In the next article in this series I will look at how to actually use a design pattern in your design once you have discovered the need for it.


Related Tags: software, design, patterns, software development, solving problems

Joshua Hayes
http://codelines.net.au
Software Developer

Your Article Search Directory : Find in Articles

© The article above is copyrighted by it's author. You're allowed to distribute this work according to the Creative Commons Attribution-NoDerivs license.
 

Recent articles in this category:



Most viewed articles in this category: