PHP Design Patterns – when should they be used?
Since the release of PHP 5, the PHP world has slowly started to get into more advanced programming, things like object oriented concepts and the use of design patterns.
WHAT ARE DESIGN PATTERNS?
In a nutshell: design patterns are standardized ways (with each having their very own name,) of solving common programming task/problems.
Over the years, programmers have identified reoccurring problems and have come up with ways to deal with those problems – by giving the programmatic-answers to those problems, a nifty name.
Common Design Patterns by name:
- Factory Pattern
- Singleton Pattern
- Observer Pattern
- Decorator Pattern
- etc …
The idea is to:
- Create a lingo that programmers can use to more efficiently speak to each other – ‘use design pattern xyz’.
- Provide a blueprint (if you will) of techniques/patterns programmers can refer to when writing code.
… in the end, it supposed to make programming easier and result in better and more consistent code.
WHEN SHOULD YOU START LEARNING AND USING DESIGN PATTERNS?
You should probably start looking into design patterns as soon as you have a handle on object oriented PHP. That said, I personally believe they start to play a valuable role in practical work, only when the PHP projects are of a reasonable size.
… there is no point in introducing the added complexity of design patterns into a simple PHP project – that’s a mistake the Java community is still trying to recover from.
THE DARK SIDE OF DESIGN PATTERNS
The problem with many common design patterns is that they add unnecessary overhead.
Many patterns assume that you are working in the enterprise arena (very big projects,) where the software will be expanding and changing over time – most (99%) PHP projects are simply not that big.
As such, the extra complexity (people have to understand the design patterns) and the extra code it usually takes to execute most patterns, makes using many design patterns a bad idea.
WHAT CAN WE LEARN FROM JAVA’S BAD EXPERIENCE?
The Java communities overly anal need to follow theoretical constructs proposed by eggheads, who apparently didn’t actually write real-world software, resulted in the sacrifice of a once usable language: Java.
Java went down the dark path of over engineering, to the point where the Java community began to revolt – it got way too complex to do anything. So now we see the rise of Ruby.
Back to patterns …
People in the Java community started coming out with all kinds of new patterns – many books were published and with each new design patterns book, Java become more and more bloated.
Some people will argue that the new design patterns were actually a symptom of the overly complex Java API. That may be true to a certain extent, but I still believe that the introduction of new design patterns contributed to the Java bloat.
CONCLUSION
I am not saying that design patterns are bad, I just think they should be used only in the right context:
you don’t need an 18 wheeler truck to move a chair…
Stefan Mischook
Pingback: PHPDeveloper.org
And what ?
Where is exapmles ?
This is not revelation
(-1)
@root,
This was not intended to be an in depth examination of specific design patterns … I just wanted to make the point that we should not try to over-engineer projects.
“This is not revelation”
… Perhaps not, but the Java community would have done well by this a few years ago.
I was only trying to offer experience from a Java developer (since 2000) who has seen some crazy things in Java – things that the php world should avoid.
Final point, this website was put up to help total beginners .. web designers. For experienced people, some of the things I cover may bore them.
That said, my articles and videos will address more advanced concepts in time.
–
To be honest, I have to check into where the PHP community stands in terms of their level of sophistication:
Do you still design by inheritance or have you seen that it is better to design by interfaces? How about AOP or dependency injection … does object oriented PHP support those designs?
Stefan, some design patterns really helps to clean up your code and improve the performance. For a single page application no ones implement design patterns, for sure. But if you just use some basic OO and your application is full of classes which you need to cooperate often, I dont think there is any alternative but using design patterns. For example I can say Factory, Singleton are very basic design patterns and you know, every programmer should use them in their code, to avoid lousy coding and performance.
AOP and MVC is something which you should think when your application just just cross the boundary of “small-application”. But what if you implement MVC (I am meaning existing large scale frameworks) but you can just implement the MVC, if you think that it may help to maintain the code.
For a single developer project design pattern and these issues are less effective than a multi developer project. You know these things are invented just to maintain the usability of you code. So if there is no chance of reusing your code and no chance that in next few years you wont open old code files, why bother using design patterns?
I think Design patterns is much more effective on the context of Ruby and Java. PHP developers can still go boom without using it. But better learning it and practising patterns like Singleton, Factory, MVC and Active Record will also increase your market value which is not avoidable at all.
Thanks for writing a cool article.
Hasin Hayder
Zend Certified Engineer
I rarely use design patterns in my PHP projects and seldom even use OO techniques. PHP has never really felt like a natural OO language and as such using design patterns in PHP code feels very strange and generally causes more trouble than its worth.
The MVC pattern is very common-place though and I think even small-scale projects can benefit from its use.