Continuing on in their series looking at the SOLID development principles, Alejandro Gervasio picks back up and looks at the "D" in the set - the dependency inversion principle.

While some central concepts in the realm of object-oriented design are generally harder to digest at first, such as separation of concerns and implementation switching, more intuitive and untangled paradigms on the other hand are simpler, like programming to interfaces. Unfortunately, the DIP's formal definition is surrounded by a double-edged curse/blessing that often makes programmers gloss over it, as in many cases there's an implicit assumption that the principle is nothing but a fancy expression for the aforementioned "programming to interfaces" commandment.

He talks about how decoupling your code and working against interfaces is only part of the equation. The other half is the actual "inversion" part of the process - the ownership that the high-level modules must have over the abstractions. He illustrates with an example, a storage module that is highly dependent on a Serializer. Using the DIP principle, he turns this around and refactors his storage class to take in an Encoder object as a part of its construction. Complete source for both versions is included.

Freek Lijten has posted the second part of his series looking at the SOLID development methodology. In this latest post his looks at the second letter in the acronym - "O" for "Open Closed Principle."

Software that requires an enormous amount of changes to implement one new feature or fix a bug is unstable and should be considered as "bad". Software should be designed so, that in case of a new feature, no existing classes should have to change. In other words: it is closed for modification. Existing software may be extended to achieve new features however.

He starts off with a "What" section explaining a bit more about what this open/closed means for your code and gets into an example showing it in a more practical way. He shows how to take the principle and refactor an API connector class to pass in the object it needs (Bike) and use that to get information (rather than just passing in the data). He uses a Factory to get the object type he needs based on the Bike type.

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 a response to a recent post on DZone.com about the "Open/Closed Principle" Josh Adell has posted an example of a " flexible and extendable command invocation solution" implementing this SOLID idea.

Let's overcome some of these issues [with only being able to extend the invoker class and that the invoker needs to know how to create commands], and also make the code even more extensible. I'll use a simplified command invoker to demonstrate.

His code is included - the creation of a "Command" interface and two comments that implement it: "HelloCommand" and "PwdCommand", each with "register" and "execute" methods. His "Invoker" class then only needs to be told how to map these commands and the "register" is called as they're needed. You can find the full example code for this invocation example in this gist.

In a new post to DZone.com Giorgio Sironi talks about the "open/closed principle" in software development and shows an example based on the design of the PHPUnit_Selenium project.

This article shows an example of how the application of the Open/Closed Principle improved the design of a real project, the open source library PHPUnit_Selenium. These design concepts apply to every object-oriented language, including Java, Ruby or even C++. The Open Closed Principle, part of SOLID set, states that software should be open for extension and at the same time closed for modification.

He starts with a little background on the project, pointing out that there's a Session object it uses for all of its testing with a magic "__call" method that handles any kind of method call to the object. This method has issues (dependencies, strict requirements for use) but can be refactored according to the Open/Closed idea to set up an array of anonymous functions that can be called as a "command". Examples of these types of classes are also included (one for the "click" action on a button and another for getting the current location).

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.

In a new post to the php|architect blog Giorgio Sironi looks at some of the good development principles that can make your applications better based on some other suggestions from Alberto Gutierrez.

Many of them are really good practices that would help most developers in the long run - after all, the only easy thing about software development is screwing it up. I feel I need to add to several of the observations on his list, both more in more abstract and more specific terms.

He talks about things like decoupling code, testing, metrics, naming conventions (and a shared vocabulary) and the role that automation can play in both your development and deployment.

Earlier in the month the Internet Resources blog posted ten principles from the PHP masters (well-known people connected to PHP and various projects). Tips include:

• Use PHP Only When You Need it - Rasmus Lerdorf
• Never, ever trust your users - Dave Child
• Invest in PHP Caching - Ben Balbo
• Make Better Use of PHP's Filter Functions - Joey Sochacki
• Use Batch Processing - Jack D. Herrington

Check out the rest of the post for helpful hints from other masters in the community such as Josh Sharp, David Cummings and Chad Kieffer.