The SitePoint Forums have moved.

You can now find them here.
This forum is now closed to new posts, but you can browse existing content.
You can find out more information about the move and how to open a new account (if necessary) here.
If you get stuck you can get support by emailing forums@sitepoint.com

If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Hybrid View

Design Patterns Catalogue

Hello, I got thinking today that with all the discussion about patterns, that what we need is a catelog of patterns that us PHP developers use day to day, so I've started this thread.

The idea is that members who use a pattern, any will do I suppose so long as the posted example works, has the revalant underlying script, etc and is PHP, will be as kind to post it to this thread?

Then, whenever someone reads about a particular pattern, or even post, they can start a thread about it, to discuss their issue(s) further in regards to that pattern. The idea is that this thread will be a catelog of pattern examples, with no discussion, so to avoid bloating this thread.

SweatJe is about to publish a new book later this year (summer) on PHP patterns, and I get the idea that this thread could be a supplement to that book, so what someone can't find in SweatJe's book, they'll maybe find it here, in this thread...

Anyways, I'll kick things off with two examples

Decorator
---------

Purpose of this pattern is to add extra functionality to the decorated class at run time. So you are not altering the class(es) that are to be decorated, thus you are extending the life of the said class(es).

Purpose of this pattern is to separate functionality away from the View. The important point of using this pattern is to remember to separate the domain from the presentation, as I have done.

For example you'd use if you wanted to output tabular data with alternating rows of colour. In this case, the Template class would have the presentational HTML for this, with the ListHelper class having the logic to decide which HTML to use, from the Template class.

PHP Patterns is still there as far as I know, but there has been no fresh content for a long time. Not sure what has happened to Harry but hope it's nothing serious.

As for a Wiki, I hope it doesn't go the same way as PHP Patterns. But where ever this catelog ends up, it has to be easily accessable for everyone, and allow discussions as I see it, as without the discussions, it's all pointless really.

The only thing wrong with forums is orginization - each pattern really should have its own thread and then we would need a "master thread".

Edit - I'm not convinced the ratings example is so hot; you're not adding functionality but rather a different type of rating. Is this really the general purpose of the pattern? No offense; I'm still learning some of this stuff.

A while back not to long ago i created a sourceforge project. http://sourceforge.net/projects/standardpattern/
With a simular idea in mind patterns with class examples and unit tests using "Open Source" programming languages php, python, ruby ...
Never actually done anything with the project.

I know the example is overly simplistic, but this is what I arrived at whilst understanding this pattern. What the example does however show, is how a Decorator should look like, from the inside point of view. Ie, how a Decorator works internally as I had trouble following what examples have in the past, been posted to these forums

I was actually looking forwards to a lot more enthusiasm for this, and now I'm disappointed that no one else has contributed

Using a SWITCH to delegate a decision has it's drawbacks, for example you need to change the script to add another decicion. With the CoR you do not need to change anything, you just add a new handler, provided you adhere to the interface.

just a suggestion, if you want to do a pattern repository, you might want to include both php4 + php5 examples if possible. alot of people still have to stay within the php4 realm because of shared hosting or other reasons. plus that might add to appeal and help people migrate over to php5 in the long run as well.

and a second suggestion, keep the thread alive, but also maybe use a wiki or repository somewhere else or even another forum attached to this one. that sums up the discussion here, but keep the discussion here cause you never know who might show up with something good to add.

i love the idea Dr. L cause idiots like me have to read books like head first design patterns and professional php5

I certainly like to see code so appreciate the postings. I also to agree firepages that without the simple description, explaining the problem and describing how it works the are not much help. Patterns are not implementations and showing implementations without context reduces the communication value of patterns.

I also have some questions about the patterns listed and I think it is the discussion if the ideas of the pattern that are of value.

For instance, overrunner's Data Mapper look a lot like the Table Data Gateway pattern to me. Table Data Gateway is a fairly simple pattern to describe and give examples of. Data Mapper is considerably more complex and is often implemented used a combination of patterns. In fact several different combinations are possible.

Dr Livingston's is a good example of Chain Of Responsibility. I would be interested in seeing other examples. There was a discussion recently that for the request the Intercepting Filter is a better choice, but for controllers Chain Of Responsibility is the way to go. So showing Chain Of Responsibility combined with the Command pattern would be of interest.

Of davro's patterns only Front Controller is a pattern that I know. I do not think HTTP Request and Controller are patterns (correct me if I'm wrong). And the Front Controller as shown does not seem to dispatch which is a central function of the Front Controller pattern. Though I like the idea of having a base Controller class for Front, Page and Application Controllers.

So showing Chain Of Responsibility combined with the Command pattern would be of interest.

I don't think that the combination of these two patterns are of any benifit to either one, as to me there is some conflict? Both patterns work on a Request of some kind, but what I can say is that Command works wonders with a Helper class, much like a ViewHelper.

This is a useful pattern to learn where you need to construct hierarchy data structures. The example I've posted below is for an XML file, which I use to construct a web page on the fly, but the hierarchy structure could be from the database. It doesn't matter really.