In his latest post Wojciech Sznapka reminds us that type hinting is important in your PHP applications and can help provide more structure and better overall code practices.

One of my favorite PHP interview questions, is: what is Type Hinting and why it’s important? Putting definition in one sentence, Type Hinting is a way to define type of parameter in function signature and it’s a sine qua non to leverage polymorphism. [...] So given the fact, that Type Hinting is optional and we don’t need to specify types of parameters passed to the method – why bother? Answer is easy: well prepared method signatures defines your model and are part of the “contract” that your code reveals to its consumers. It also prevents many silly errors and keeps codebase clean and coherent.

He talks about the best practices on using type hinting including where to put them (in an interface or base class or child class?) and some of the pros and cons of each. He also points out that some practices around type hinting, like overriding the hint and calling the method with unexpected/variable input, should be avoided (see the L in SOLID).

On NetTuts.com today they've continued their series covering the SOLID development principles with the next letter in the acronym - "L". It stands for the Liskov Substitution & Interface Segregation Principles. The tutorial also talks some about the "Interface Segregation Principle" as they go hand-in-hand.

The concept of this principle was introduced by Barbara Liskov in a 1987 conference keynote and later published in a paper together with Jannette Wing in 1994. Their original definition is as follows: "Let q(x) be a property provable about objects x of type T. Then q(y) should be provable for objects y of type S where S is a subtype of T." [or more simply] "Subtypes must be substitutable for their base types."

They include some example PHP code showing a base "Vehicle" class and first an example of doing it correctly (with the Template design pattern) and an example of an incorrect method, complete with tests. They then get into the Interface Segregation Principle, an interface that can be depended on to use the module, with the same car-related examples.

On PHPMaster.com there's a new post in a series looking at the SOLID design principles in PHP development. In this new tutorial they try to dispel the myth that constructors break the Liskov Substitution Principle ("L" in "SOLID").

Rants aside, the morale of the story can be boiled down to the following: “Object construction is not part of the contract honored by its implementers”. It’s easier to grasp concepts by example rather than reading dull theory, so in this article I’ll be demonstrating from a practical standpoint how the implementation of different constructors down the same hierarchy isn’t a violation of the Liskov Substitution Principle, which is a reason why you shouldn’t fall into the temptation of tainting your interfaces with constructors.

He illustrates the point with a simple PDO class that implements a "DatabaseAdapterInterface" interface that defines its own constructor that follows the defaults of the PDO extension. He goes on and changes the constructor for the class a bit to take in an array of config options rather than the DSN/User/Password combo. Inside of this constructor, those values are then taken and pushed into PDO to create the connection. He also suggests one other solution - the injection of a connection object ("ConnectionDefinition") into the constructor instead of the configuration directly.

In this new post to his site Freek Lijten picks back up his series on the SOLID design principles with a look at the "L" in the acronym - the Liskov Substitution Principle.

The Liskov Substitution Principle (LSP) was coined by Barbara Liskov as early as 1987. The principle is very tightly connected to the earlier discussed Open Closed Principle. A good way of adhering to the OCP is understanding and implementing code that uses the Liskov Substitution Principle. In this article we will discover why and how.

He gives a more understandable explanation of what the rule tries to suggest - a standardized interface that each of his "Bike" instances follows to ensure the contract of a consistent API. Then each of the child classes can reliably assume that there are methods they can use because they'll always inherit them.

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.