The TutsPlus.com site has posted the next tutorial in their "Object-Oriented Autoloading in WordPress" series - part two - expanding on the basics presented in the previous part of the series.

In the previous tutorial, we covered a handful of concepts, all of which are going to be necessary to fully understand what we're doing in this tutorial. Specifically, we covered the following topics: object-oriented interfaces, the single responsibility principle, how these look in PHP [and] where we're headed with our plugin.

[...] Ultimately, we won't be writing much code in this tutorial, but we'll be writing some. It is, however, a practical tutorial in that we're performing object-oriented analysis and design. This is a necessary phase for many large-scale projects (and something that should happen for small-scale projects).

First they briefly cover the environment you'll need to follow along (already set up if you followed along with part one). They then get back into the code, evaluating the current state of the custom autoloader and investigating how it can be broken down into a class and a set of methods instead of procedural code. They work through the different functional parts of the autoloader and how to break it down into classes with only one job (the "single responsibility principle"). They end up with the autoloader that uses NamespaceValidator, FileInvestigator and FileRegistry instances to get the job done.

The TutsPlus.com site has posted the next part of their series looking at autoloading in WordPress plugins. In this latest post the most from just the namespacing and setup into the actual code - creating some simple object-oriented classes that can be easily autoloaded.

I recently wrapped up a series in which I covered namespaces and autoloading in WordPress. If you're not familiar with either of the above terms, then I recommend checking out the series. [...] While working on the series, specifically that of the autoloader, I couldn't help but recognize a number of code smells that were being introduced as I was sharing the code with you.

This isn't to say the autoloader is bad or that it doesn't work. If you've downloaded the plugin, run it, or followed along and written your own autoloader, then you know that it does in fact work. But in a series that focuses on namespaces—something that's part and parcel of object-oriented programming—I couldn't help but feel uncomfortable leaving the autoloader in its final state at the end of the series.

They move away from just autoloading and namespacing quickly and move into OOP concepts like interfaces, implementing them, the "single-responsibility principle" and a few other helpful principles. They define the goals for the work ahead and move into the code, updating the current state of the plugin to use these new ideas.