There are plenty of articles that explain what design patterns are, and how to implement them; the web doesn't need yet another one of those articles! Instead, in this article, we will more discuss the when and why, rather than the which and how. I'll present different situations and use-cases for patterns, and will also provide short definitions to help those of you who are not so familiar with these specific patterns.

They've broken them up by topic instead of by the patterns themselves with sections like:

• Finding the Data We Need
• Reusability
• Discover-ability
• Singularity
• Controlling Different Objects

There's also a few sections that look at other patterns that really only have a handful of uses - like the Decorator, State and Composite patterns.

PHP is the world's most popular scripting language for many different reasons - flexibility, ease-of-use, among others - but often times coding in PHP, or any language for that matter, can get rather monotonous and repetitive. That's where a PHP framework can help. [...] Frameworks can also help beginners to build more stable apps by ensuring proper database interaction and coding on the presentation layer. This allows you to spend more time creating the actual web application, instead of spending time writing repetitive code.

They touch on why you should use a framework and when are appropriate times to make them a part of your development. They also point out a few common mistakes that are often made when using frameworks like using a framework above your skill level or ensuring that all other technologies will work with your framework of choice.

They finish the article off with a look at the features of five different frameworks:

• Zend Framework
• CakePHP
• Symfony
• CodeIgniter
• Seagull

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.

Stefan Mischook describes the patterns simply, as nothing more than standardized ways of solving common programming problems. He lists a few of the more well-known patterns and answers a few common questions developers have about them:

• When should you start learning and using design patterns?
• The dark side of design patterns (when should I use them?)
• What can we learn from Java's bad experience?

I love his final comment - it sums the design pattern experience up well:

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

This is a short smug entry, written in the "Yeah, well I liked them before they even had a record deal" style associated with trend snobs. Except in this case, its the opposite, I am claiming that I hated something back when it was cool. Thanks to blogging my opinion earlier, I even have proof! PHP should stand for Pretty Huge Problem.

He mentions some of the rants, langauge switchers, and general complaints that have come up about PHP, including the combination of code and HTML, the "safe mode" feature, and PHP's "battered on" nature of development. He also goes off a bit on the (inevitable) backlash that Rails and Ajax will see in the future, and wonders how far off it will be.]]> Thu, 23 Feb 2006 07:26:24 -0600