Last week I gave a presentation to my team on dependency inversion and dependency injection in PHP. Dependency inversion is the “D” in the the SOLID object oriented design principles, and dependency injection is a design pattern for implementing it.

We previously learned the single responsibility principle (PDF) (the “S” in SOLID). To me, dependency inversion is the next logical topic. Single responsibility is about how to write objects that do one thing; dependency inversion is about how you wire those objects together into robust, working software.

This was a fun presentation, and I think the slides work well even without my narration. Several of the code examples are from the new version of Shashin, where I’m applying the principles. I’m still learning how to best apply them, so feedback in the comments section is welcome.

A couple weeks ago I gave a presentation to my team, based on Malcolm Gladwell’s Outliers: The Story of Success. I focused on his analysis of mitigated speech (when we downplay or sugarcoat the meaning of what we say, usually out of deference to authority). Mitigated speech has been a key factor in numerous airplane crashes, when the crew did not voice safety concerns clearly enough to their captain.

Gladwell’s examples from black box recordings are astonishing. In many cases everyone in the cockpit except the captain knew the plane was in serious trouble, but even then wouldn’t speak up forcefully (typically the captains were good pilots, but were exhausted and weren’t picking up the hints from their crews). They’re powerful examples of the importance of being assertive, and just how hesitant most of us are even when it’s obviously vital to speak up. And my presentation was, I hope, more entertaining then some stereotypical HR assertiveness training class.

The last couple slides show similar examples from The Clean Coder: A Code of Conduct for Professional Programmers, about the importance of saying no and not being passing aggressive.

Here are my slides (posted on SlideShare.net)

Ron Jeffries wrote a post a couple days ago with a title indicating its about databases, but then he proceeds into a test-driven development (TDD) coding exercise. Halfway through, an ostensible reader interrupts:

Hey! I thought this was supposed to be about databases???

Hey, yourself. Try to pay closer attention. This is totally about databases.

Why is this even remotely about databases???

Well, here’s why:

We have just defined a core element of our member database record, namely the purchase count, and made sure that it works. Now when we read a member record in from our database, we can instantiate it into our class MemberRecord and send it messages to decide what to do. This is OO here, my young padawan, and that’s how we do it.

Yeah, sure, old man, but what about the membership number? That’s the key, according to the story, and you don’t even have it. And isn’t there just a small matter of actually storing and retrieving these babies?

Patience, youngling. Each thing comes in its time. Let’s see what the next tests bring us.

His post is a good illustration of the revelation I had when first learning Agile coding practices: they let you start in the middle, with the business logic. A common traditional approach is to instead define a database schema first, and then deal with the UI and business logic. There are 2 problems with this traditional approach 1. the database is the hardest layer to change, and your design is likely most volatile in its early stages, and 2. it makes it that much easier to end up tightly coupling the components of your application together.

By starting with the business logic and no supporting infrastructure other than your tests, you have no choice but to fully decouple the application logic from the UI and the database. Then when your boss says, “we need to make a mobile version of this app by Friday!” you can work on the new mobile UI design without having to cut through a tangled thicket of blended UI and business logic.

Having said that, there are challenges with mimicking complex interactions with the database and UI layers through unit tests. I consider myself a novice with Agile techniques, but I’ll share what I’ve learned so far:

• For my Shashin project, which pulls data from Picasa json feeds, I simply saved copies of some feeds to local files, and my tests can talk to those files. This allowed me to keep developing while offline (on a flight to Hawaii!) which is very cool.
• There are the object mother and test data builder patterns but both can entail a fairly heavy degree of typing when dealing with large or complex data sets.
• My team at Penn is currently trying out FitNesse, which lets you specify your inputs and expected outputs through simple wiki tables (which you can paste from a spreadsheet). This seems about as lightweight as you can get. Although it’s an acceptance testing tool (not a unit testing tool), it can still help drive your design. If you follow specification by example practices, and write your code so that it can take inputs and send outputs to a FitNesse test fixture OR a database and a form, then congratulations, you’ve decoupled your code from the database and UI!

Toppa.com has become a quiet place in recent months. I’ve been spending what time I have on coding Shashin 3, so I haven’t been blogging. I have been applying Agile coding practices to WordPress plugin development, and it’s more than I bargained for. I could write a book about it, but I’ll probably never have time, so I’ll see how far I can get with a series of blog posts instead. Here are some key points I hope to expand on in upcoming posts:

• Testing: a typical WordPress plugin is sprinkled with calls to custom WordPress functions and hooks, so how can you unit test anything? Also, PHPUnit is a command-line utility, so how can you test plugin code that’s meant to run from within WordPress, which is a web app? The answer to the first question is to pursue a combination of isolating your WordPress dependencies, and running them through a facade (my toppa-libs library provides one, but it’s coverage of WordPress functions is still limited). An answer to the second question is SimpleTest, which is designed to run tests through a browser. I’ve written a plugin that runs SimpleTest from within WordPress, so you can do integration testing: SimpleTest for WordPress (which I hope to have up at wordpress.org soon). Update 6/15: it’s now available at wordpress.org
• Which PHP version to use? PHP 5.3 provides a decently comprehensive object oriented toolkit. But WordPress understandably stays at least a couple years behind the current PHP version, given the widespread use of WordPress (not every hosting provider keeps up with the latest PHP releases). The upcoming WordPress 3.2 release will have PHP 5.2.4 as a requirement, so I’ve decided to have the same requirement in Shashin. That means I can use type hinting and autoloading, but not namespaces.
• Code organization: WordPress gives you custom hooks and functions, but how you organize your code is completely up to you. As a result, a lot of WordPress plugins are huge, single files that are a jumble of code for display and application logic. In Shashin I’m using output buffering to create pseudo-templates for display code, and for the application logic, I’m sticking to the single responsibility principle, which means I have small classes and small methods.
• Performance: given the processing power of modern computers, an Agile principle is that you code for readability and maintainability first, and worry about performance only when there is evidence that you may need to sacrifice some of that readability to improve performance. Sticking to this principle is a challenge with WordPress. WordPress sites are deployed in a huge variety of environments, with differences in site configurations, traffic, and the number and type of other plugins in use. This leads to a natural tendency to code defensively for performance. I’ve tried to approach this not by sacrificing readability, but by having a dependency injection model that’s careful to not make unnecessary copies of objects, and by organizing my code to minimize any non-essentials calls when particular hooks are invoked.
• WordPress itself will try to thwart you in writing Agile plugins, as there is nothing Agile in how WordPress itself is written (this is not a criticism of its creators, as only since PHP 5 could you even really consider an object oriented approach with PHP, and WordPress has been around since long before PHP 5 became commonly deployed). A key decision is how far you want to go in isolating your code from direct dependencies on WordPress functions and classes (as they are not written against any interfaces). The more direct your dependencies, the harder it is to unit test anything (and then you can’t use your code outside of WordPress either). There is also no consistent error handling – some WordPress functions may return a WP_Error object, or false, or null, or something else. None throw exceptions. You’ll need to investigate each individual function to find out what variable type its return value will be under different circumstances.

I hope to get SimpleTest for WordPress up at wordpress.org soon, so I’ll have more to say about testing in WordPress next.

Over the past several months I’ve been following Agile coding principles in my work, as described by Bob Martin and others (see, for example, Clean Code, Agile Software Development, and Growing Object-Oriented Software, Guided by Tests). Applying these principles in PHP presents some challenges. Applying them to WordPress plugin development presents even more challenges. This is the first in a series of posts on how I’m dealing with those challenges. My Google searches about PHP and Agile coding don’t turn up much, so I figure I can break some new ground 😉 . But I don’t consider myself an expert – feedback is welcome.

If you follow the Agile principle of small methods and small classes, your projects will consist of a large number of small files. In Java, this doesn’t matter much – the project is compiled before it’s deployed. But PHP is a scripting language, so it’s compiled on the fly. include and require statements can have a moderately expensive performance cost (see here and here). So what’s the best way to include your files for code readability, and for efficiency?

require_once vs require

I always use require_once to include a required file. I don’t use include, which allows the compilation to proceed even if the file is not found (a class file isn’t going to be optional). require_once has a reputation for being slower than require, but this benchmarking indicates otherwise (I wouldn’t consider that an exhaustive study, but it’s enough that I’m not going to lose sleep over it). This way I don’t have to worry if a file has been included somewhere else already. If you have lots of small classes, used in various places, require_once can save you from that headache.

Where to put your require_once calls

There are three options:

1. The simplest option, and worst from both a performance and code integrity perspective, is to include all your project’s class files in the initializing script. Dependencies between classes will not be evident to someone reading your code. That is, if you tried to use one of the classes in a different project, and that class has dependencies on other classes, the class would fail to compile unless you read through the class to find the dependencies and added them to your new calling script (and then you’d have to manage the dependencies in two places). It’s also unnecessarily wasteful. Any given execution path through your project likely only requires a subset of your classes, so there’s no reason to load them all for every single http request.
2. The second and most preferable option is to include all the class files a given class depends on at the top of that class file (before the class line). This is common practice in languages I’m familiar with. From a readability perspective, the dependencies are clearly stated at the top of the class file. From a performance perspective, you’re only loading what that class needs. And from a flexibility perspective, that class can now be used outside the context of any particular calling script (as long as you package it with what it depends on). Note that if you are doing dependency injection, you’ll be passing in already instantiated objects to the dependent class, so your file includes will be one step removed from the class where the objects are actually used. The simplest way to think about this is to include the class file dependencies wherever there are new calls on those classes.
3. A third option is something I was doing, until @speno showed me the error of my ways. I put the require_once statement for a class file on the line before calling new on that class, regardless of where I was in the code. There is no technical problem with doing this – PHP will read the class into memory – it doesn’t matter if you’re inside a method. I did it in pursuit of improved performance: dependent classes are loaded only exactly when they are needed. The problem, however, is that the dependencies are now buried in the code of the class, making the reader of your code do more work to find them (and risking missing them, which leads to bugs…). A tenent of Agile programming is that you optimize for readability first, and that you sacrifice that readability for performance only when there is a demonstrable performance problem to address. What I was doing is an example of premature optimization (and the “gut feeling” optimizations many of us do, like I did, often turn out to not be optimizations at all when you profile the actual performance).

If you do have performance problems, file includes are probably not the first place to look. Database queries are the more common culprit. But if you do need to reduce your hits on the filesystem, you should look at opcode cachers, such as APC (or, for WordPress, the W3 Total Cache plugin) before you contemplate writing hard to read and maintain God objects.

Note: this is a revised version of the original post.