In this two-part tutorial I'll be showing you, in a step-by-step fashion, how to use the goodies offered by closures in the implementation of an object-based, easily extendable template system. This system will allow you to embed anonymous functions easily into template files, and call them as typical view helpers, too.

He starts the process of creating the templating system by defining two interfaces, the View and DataHandler. Using these as a base, he creates an instance of the ViewInterface (a "View" class) that can set the template file to use, set values to be displayed and render the formatted output. Included is a basic template and how to use the View class to set values into it. The "render" method is called on the view and the HTML markup is produced. The closure comes in when they try to call a value "clientIp" that needs to do something more complicated than just having a string assigned to it.

Even when the formal definition of the LSP makes eyes roll back (including mine), at its core it boils down to avoiding brittlely-defined class hierarchies where the descendants expose a behavior radically different from the base abstractions consuming the same contract.

He includes an example with a "deleted scene" from the Matrix depicting an attempted override of the PDO functionality with a subclass that, unfortunately, does not match the original's structure/method definitions. The problem was in the difference between the method signature for the "query" method. It help resolve situations like this he recommends creating a "contract" in the form of an interface your code can implement, forcing it to conform to a certain structure. Using this, he provides a rewrite of the "PdoAdapter" class to match the original signature

PHP provides a number of predefined interfaces and classes that can really make your life as a developer easier but which are often overlooked. The functionality offered by the Standard PHP Library (SPL) and the predefined interfaces is extremely cool and very powerful but very underutilized. [...] I thought I'd write a few articles with examples of how I've used these classes and interfaces in the hope that someone would find it useful. I'd love it if people felt like commenting with their own examples too. I'll start with a quick look at the Countable interface.

He includes sample code for classes using the Countable interface and defining the custom "count()" method inside. This method lets you define how the object will behave when something like count is called on it. His examples show returning the number of items in a private variable, determining the state of an object and including logic to only find valid data (like from a database table).

The BrowseNodes tool automatically gets all the child BrowseNodes and their names. The program recursively traverses the BrowserNode hierarchy and returns all the BrowseNodes and their respective names. You can display the nodes on the console or save it to a CSV file. You can also include the library in your existing projects to process BrowseNodes.

You'll need curl support on your system to make it work. Several code examples are included showing how to grab a certain node, showing a list of nodes, saving the node information to a CSV, changing locales and getting the parent node for the current node.

Static helpers seem to be a great idea at first glance, as they're reusable components that don't require any kind of expensive instantiation for doing common tasks [...]. But the sad and unavoidable truth is in many cases they're simply wrappers for procedural code, which has been elegantly hidden behind a "class" construct. So what's wrong with this? Well, even in the most harmless situations, when you use a static helper that produces a deterministic output, you're actually throwing away the advantages that OOP provides.

To illustrate, they create a basic validation class that can check for things like valid emails, float values, integers and URLs using PHP's filter_var function. They point out that the class is difficult to extend and that it is doing too many things to be correctly considered a "piece" of functionality. To correct the problem, they opt for a different approach - an abstract class acting as an interface to structure custom validators against. This provides set/get methods for things like the error message and value to evaluate. The implementation of the validators on top of this class is coming in the next part of the series.

In this two-part tutorial, I show why the use of static helper classes can be detrimental to building robust and scalable object-oriented applications in PHP (though you should take into account that the concept is language agnostic). I also implement a set of instantiable, fine-grained validators, which can be easily tested in isolation, injected into the internals of other objects, and so forth.

Their set of "concrete validators" are all based off of a validator interface/abstract class and check things like email formatting, floats, integers and URLs. Also included are a few examples of using the validators in a sample script.

if you've already read the two installments that precede this one, it's probable that you're familiar with the inner workings of this sample ORM. In those chapters I implemented the ORM's data access and mapping layers, along with a simple domain model. To be frank, the development of this last tier is entirely optional; however, it's useful for demonstrating the ORM's actual functionality in the deployment of a blog program, which naturally will handle some "typical" domain objects, namely blog entries, comments and authors.

They share the code for creating proxy objects and, using a "poor man's dependency injection container" made from a factory method, interfaces and service classes to handle the results.

Especially as for different libraries a different subset of the community could end up collaborating. Here I see 3 options: 1) each library bundles the interfaces (even though they sit in some common namespace), 2) each project asks their users to fetch the common interfaces from some other place 3) runtime "coupling". Option 3) doesn't exist today and is what this blog post is about.

He introduces the idea of a "spl_register_compatible_interface" method that would let you compare interfaces to see if they'd mesh. There'd still have to be a lot of communication between developers to make things match, though. He suggests three "practical issues" that libraries/tools would have to overcome to use a system like this - each framework has their own interface setup, the lead time for collaboration could be too much to be worthwhile, a lack of interest from some about collaboration and the idea of competing interface methods.

He's looking for feedback from the community on the idea(s) though, so go and leave a comment with your thoughts!

Though in the past they enjoyed both popularity and a certain amount of prestige, without a doubt Singletons have progressively become one of the most evil and despicable villains in object-oriented design. Singletons earned their bad reputation for a reason: bringing them to life requires the programmer to deal at least with a static method. This is simply an elegant masquerade for creating a global access point (which in most cases is mutable as well) throughout an entire application. And we all know that global, mutable access is unquestionably a bad thing that must be avoided at all costs.

In this first part (of two) of the series they introduce the Singleton pattern and show how, via an example of using a database adapter interface to work with a MySQL database, in a tightly coupled example. In the second part of the series, they'll show how to break these apart using dependency injection.

Together with its more famous brother "Iterator", they are currently the two only implementations of the "Traversable" interface, which is needed for objects so they can be used within a standard foreach() loop. But why and when should we use the iteratorAggregate?

He answers his question with an example - a book that contains chapters. With a normal iterator you'd have to define standard functions (like valid, rewind or key). Using the IteratorAggregate you can push items into an internal array (like chapters in a book) and call a "getIterator" method to get this set. He also takes it one step further and shows implementing the "Count" interface to make it easier to get a total count of the items in the iterator. Sample code is included to help clarify.