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.
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…