The Not So Simple "Hellow World"

Soldato
Joined
16 Dec 2005
Posts
14,443
Location
Manchester
Over the last few days I have been studying OO Design Patterns as applied to PHP. Since PHP5 supports OO programming, I aim to learn how to get the most out of it.

For those who don't know, Design Patterns are basically solutions to common problems in OO programming. These solutions are special in that they maximise re-usability, de-coupling and lots of other OO type stuff that is good! :p

While reading around, I found a crazy example of how Design Patterns can be a little overkill...

http://www.phppatterns.com/doku.php/design/hello_world_in_patterns

I would pay good money to see a lecturer start Lesson 1 of OO programming with that particular Hello World example :p

"Now for a simple example of OO programming..."

*slide shows with 160 lines of code*

class: :eek:
 
I've detested that blog article (and the one it refers to) for throwing me off course ever since I truly learned and realised what design patterns are. They are not goals to aim for, they are simply common application design patterns that have been labelled so developers can discuss them, tag them, remember them, etc. etc.

The first rule of Design Patterns is knowing when to apply and not to apply them.

and FYI, the "Bible" of Design Patterns is Martin Fowler - Patterns of Enterprise Application Architecture.
http://www.amazon.co.uk/Enterprise-Application-Architecture-Addison-Wesley-Signature/dp/0321127420
 
They are not goals to aim for, they are simply common application design patterns that have been labelled so developers can discuss them, tag them, remember them, etc. etc.

Slightly more than that, I'd say; they're solutions to common problems that have been labelled.
 
Last edited:
the "Bible" of Design Patterns is Martin Fowler - Patterns of Enterprise Application Architecture.
http://www.amazon.co.uk/Enterprise-Application-Architecture-Addison-Wesley-Signature/dp/0321127420

An excellent book, although I would say that the bible on the subject is probably the original "gang of four" book: Design Patterns: Elements of Reusable Object-Oriented Software by Gamma et al, which covers the basic core patterns. Fowler himself calls it "the seminal book on patterns".
 
Last edited:
I agree design patterns have their place, but I do feel sometimes they can be abused and used for the sake of using it, leading to 'over'-engineer code, as the above blog proves.
 
Simply knowing the Design Patterns can be a goal to aim for. I know, even as a complete DP noob, that there is a time and place for them and I would never dream of attempting the Hello World example I posted :p

I would buy the original GoF book, but I think it is a little bit beyond my current abilities. It has been a year or two since I did any serious OO programming, so I have pretty much forgotten a lot of it. Maybe in a little while when I am back on form :p
 
One thing Design Patterns certainly shone light on for me, was how having very concise behaviours encapsulated within objects is better than having objects do a mish-mash of multiple behaviours.
 
One thing Design Patterns certainly shone light on for me, was how having very concise behaviours encapsulated within objects is better than having objects do a mish-mash of multiple behaviours.

Definitely. It is so tempting when creating a class to add in lots of "features" that you may never actually use and you are in danger of making a "God class", or in the least a class you can't easily reuse.

Just from my few days of looking at Design Patterns I have seen how you can add functionality and behaviours to your classes without having to rewrite them or depending too much on inheritence [again, something you can get carried away with!].
 
An excellent book, although I would say that the bible on the subject is probably the original "gang of four" book: Design Patterns: Elements of Reusable Object-Oriented Software by Gamma et al, which covers the basic core patterns. Fowler himself calls it "the seminal book on patterns".
Just seen this post, someone once said the GoF book (that you have posted) is the old testament, and Martin Fowler's is the new testament. :)
 
One thing Design Patterns certainly shone light on for me, was how having very concise behaviours encapsulated within objects is better than having objects do a mish-mash of multiple behaviours.

that's one thing that I really suffered from coming from a procedural starting point to OO. I just wanted one class to do absolutely everything, and it's only recently that I've been able to write concisely as a reflex rather than having to really think about it.

still love planning what things are going to do, though.
 
Over the last few days I have been studying OO Design Patterns as applied to PHP. Since PHP5 supports OO programming, I aim to learn how to get the most out of it.

For those who don't know, Design Patterns are basically solutions to common problems in OO programming. These solutions are special in that they maximise re-usability, de-coupling and lots of other OO type stuff that is good! :p

While reading around, I found a crazy example of how Design Patterns can be a little overkill...

http://www.phppatterns.com/doku.php/design/hello_world_in_patterns

I would pay good money to see a lecturer start Lesson 1 of OO programming with that particular Hello World example :p

"Now for a simple example of OO programming..."

*slide shows with 160 lines of code*

class: :eek:

my lecturer showed us a few examples of stupidly complicated hello world programs in first year :D
 
Just seen this post, someone once said the GoF book (that you have posted) is the old testament, and Martin Fowler's is the new testament. :)
Interesting, not heard that :) I'm a big fan of the Fowler book (and his others) but not really as in intro to design patterns as it doesn't cover the "core" patterns, but instead builds upon the groundwork laid by GoF. His style is a lot more approachable than GoF though, and both books would be useful to anyone seriously interested in patterns.
 
One thing Design Patterns certainly shone light on for me, was how having very concise behaviours encapsulated within objects is better than having objects do a mish-mash of multiple behaviours.

Reminds me of a quote I saw the other day, the Pasta Theory of Software:

Nearly every software professional has heard the term spaghetti code
as a pejorative description for complicated, difficult to understand,
and impossible to maintain, software. However, many people may not
know the other two elements of the complete Pasta Theory of Software.

Lasagna code is used to describe software that has a simple,
understandable, and layered structure. Lasagna code, although
structured, is unfortunately monolithic and not easy to modify. An
attempt to change one layer conceptually simple, is often very
difficult in actual practice.

The ideal software structure is one having components that are small
and loosely coupled; this ideal structure is called ravioli code. In
ravioli code, each of the components, or objects, is a package
containing some meat or other nourishment for the system; any
component can be modified or replaced without significantly affecting
other components.

We need to go beyond the condemnation of spaghetti code to the
active encouragement of ravioli code.
 
Back
Top Bottom