I had no idea when I started making slides for this portion of my talk (Bringing Good Design to the Table) at SunshinePHP that this would be such a contentious issue. I should have known in hindsight, but I didn't expect this to be such a holy war. In the future I'll know better and preface this section quite strongly with "my opinion" caveats.

So that being said, I decided to outline those conventions again here. I'm going to try to give more of my reasoning behind the different choices below, to hopefully stem a few of the objections. Then again, nobody likes being told that the way they're doing things is "wrong" so let me again say that this is my opinion. I didn't create this convention and I'm not the only one that uses it, this just happens to be the one I'm most comfortable with. Maybe this will become part of a series exploring the contents of my talk, who knows.

Read more of this post »

Last week I worked with one of our junior engineers on a design exercise and I thought I'd share. We're working on a theme system based on plug-able widgets, and we have a Widget_Manifest class that generates an array of widget objects based on the contents of a directory on the file system. Here's what we started out with:

Read more of this post »

Simply put, unit testing code with lots of magic is hard, much harder than it needs to be. However, if you seek out the magic in your code and replace it with clear, explicit calls to well-defined functionality, testing becomes much, much easier.

Take this common use of magic functionality: __get. This is often used to create fake public properties on an object. Probably the most egregious use of this magic method (that I've seen multiple times in various codebases) is code like this:

public function __get($name)
{
    $propName = "_$name";
    if (isset($this->$propName) {
        return $this->$propName;
    }
}

Read more of this post »