Contact Us

How Design Patterns solve Problems

Posted on 28/4/07 by Tim Koschützki

Now that is a really important question. Generally you can go by this definition:

A design pattern names, abstracts and identifies the key aspects of a software design by identifying the participating classes, objects and instances, their roles, collaborations, interrelationships and the distribution of responsibilities.

However, the choice of the programming language is important. For example, PHP5 treats instances of objects as references, which might change the implementation of a certain design pattern drastically. Or, what if the language you are using does only support object composition, but no class inheritance?

There are many language-specific problems occuring when you wonder how design patterns solve design problems. That's one reason why I have created this website - to only care about PHP.

In the following, the definition above is explained further.

Finding Appropriate Objects

Object-Oriented design methodologies favor many different approaches. You could single out the nouns of a problem statement and define the corresponding objects. The verbs in the statement would become the objects' operations. Or you could concentrate on the responsibilties in your system. Or you could model the real world and translate all subjects and their actions into your design as objects. There is always disagreement on which approach works best and sometimes one approach is better suited to a problem, than the others.

The last approach, modeling the real world often works. However, when you are faced with a problem where your object-oriented design ends up with no classes as counterparts for the world entities, one might be in trouble if there is no guide.

Such a guide is a design pattern. When modeling objects becomes difficult, a design patterns helps you to identify the needed objects - even if they are low level objects like Sessions, Cookies or even simple Collections. If you strictly model the real world, your design might not be flexible enough. For example, an object that represents an algorithmn, a state or a process is not found during the analysis phase. It's found later when one wants to make the design more flexible and reusable.


You can skip to the end and add a comment.

Rick Jayne said on May 01, 2007:

Are there other uses for design patterns than finding the appropriate objects and providing a fail-safe solution to a given problem?

[...] read more | digg story [...]

Peter Goodman said on Jun 18, 2007:

I think it's useful to mention how some design patterns, altho useful for some things, can result in more problems in the long run. One such example is the Singleton pattern. It acts like a global variable and causes coupling issues.

Tim Koschuetzki said on Jun 18, 2007:

Correct, Peter. Since my singleton article is in the works I will pay extra attention to such issues. Would you like to help me write it?

Peter Goodman said on Jun 18, 2007:

I actually wrote quite a long article about them a while ago:

It addresses global variables, singletons, and public static methods.

Tim Koschuetzki said on Jun 18, 2007:

Good stuff. :) Just printing it out. Too bad it's already 11:30pm here and I need to hit the sack soon. :/

However, I will voice my opinion tomorrow here I am sure.

Peter Goodman said on Jun 18, 2007:

Good to hear, I'm looking forward to your article.

deltawing1  said on Jun 25, 2008:

"For example, an object that represents an algorithmn, a state or a process is not found during the analysis phase."

Yup exactly :-)
While analyzing objects during the requirements stage can be very useful for applications modeling the real world, it is highly unsuitable for business applications.

Tim Koschützki said on Jun 25, 2008:

deltawing1: Do you have an example business application where this makes no sense?

This post is too old. We do not allow comments here anymore in order to fight spam. If you have real feedback or questions for the post, please contact us.