The concept of generators was recently proposed for addition in PHP’s core (Possibly for 5.5.0). While I believe that this is a great tool, it appears that many PHP developers aren’t familiar with the concept of generators. So I thought I would take a little time and explain some of how it works, and how it can be used to greatly simplify code.

One of the most powerful changes that PHP5 brought to the table was the ability to autoload classes. It’s such a useful tool that it was the first standard the FIG group put forth. Almost every single major PHP framework and library uses an autoloader to include its classes. It always felt somewhat wrong to me to autoload in production at runtime. So I decided to give it a bit more exporation…

This morning I was asked a question that took me by surprise: “Your examples for PasswordLib are in OOP style, how do I write it in procedural style”… This took me by surprise, because the examples actually are in a procedural style. So I felt that I should write a post about the real differences between OOP and Procedural coding styles. Hint: whether you use classes and objects or not has very little to do with the answer…

Very often when we look at a class diagram for a new application, it’s quite overwhelming. There are tons of classes, all interacting with each other. These interactions are everywhere. It actually resembles a spider web of interaction. Trying to decode this web to figure out what the application is doing can be a lesson in futility for some applications.

How then, can we design an application such that it’s easy to follow? How can we build an application that’s easy to understand on all levels? The answer is deceptively simple: by using layers. Let’s explore how we can use layers to help build our applications in a clean, easy to follow and maintainable manner.

Time for some more shameless self-promotion… I’ll be doing a talk at the New York PHP group on Tuesday May 22, 2012. I’ll be discussing some Object Oriented design principles and how to apply them to your projects. We’ll specifically discuss the STUPID and SOLID principles. Here’s the full abstract:

A common problem that developers face when building applications is how to allow the application to be “plug-able” at runtime. Meaning, to allow non-core code to modify the way an application is processed at runtime. There are a lot of different ways that this can be done, and lots of examples of it in real life. Over a year ago, I wrote a StackOverflow Answer on this topic. However, I think it deserves another look. So let’s look at some patterns and common implementations.