On PHPMaster.com today there's a new post from Alejandro Gervasio about a part of the SOLID development methods - the Liskov Substitution Principle - the idea that objects should be replaceable with instances of their subtypes without a change to the architecture of the application.

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

In another part of their series looking at the SOLID principles of software development, DevShed focuses again on using LSP (the Liskov Substitution Principle) to help you organize your application (part one is here).

Even though its formal definition is somewhat hard to grasp, in practical terms it states that methods defined in a base class (or interface) and their derivatives must have the same signature, preconditions should be weakened in the formers, and post-conditions should be strengthened. In addition, if methods in subtypes throw exceptions, they should be of the same type as the ones thrown by the parent abstraction.

You'll need to read the previous tutorial for things to make sense here. They take off running from there, though and get straight into refactoring the previous example to correct a violation of LSP. In the end you'll have a layout/view system that correctly follows the principles and is pretty simple to use too.

On DevShed today there's a new tutorial posted talking about the Liskov Substitution Principle (part of the SOLID set of principles) and how to use it in a practical example using some object-oriented PHP.

However, not all is bad with Inheritance. When used properly it can be a great ally. The question that comes to mind is: how can you keep away from building derivatives that behave totally different from the chosen abstraction(s)? Here's exactly where the Liskov Substitution Principle (LSP) comes into play.

They choose to illustrate the principle in the form of a view renderer that, when an unintentional issue happens, throws a new exception. He creates the abstract class to generate the view objects and creates a few child objects that extend it. using these, he creates a set of templates that render a header/footer/body with the data given. The problem comes up when he tries to work with his objects and a partial view instead of a composite view is passed in.

It's a complicated situation to follow, but it does help make the principle a bit more clear. I'd suggest following it all the way through and possibly even trying out their code (included) to make it even more clear.

In a previous post to the Zend Developer Zone Keith Casey talked about the SOLID principles of software development, a set of guidelines that can help to make software more maintainable and easier to work with. In this new post he looks at the "L" in SOLID, the Liskov Substitution Principle.

So the Liskov Substitution Principle boils down to: method/class preconditions cannot be strengthened, method/class post conditions can't be weakened, all exceptions thrown must equally interchangeable and method signatures should be completely compatible.

To help make this all a bit clearer, he includes some code showing a basic class (Rectangle) and how difficult it can be to try to appease all of the principles above without the "fix one, break another" scenario. On comment to the post suggests something that might help things a bit - programming by contract.