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).

Nikita Popov talks about the SOLID coding practices and creates his own acronym for the complete opposite - STUPID (Singleon, Tight coupling, Untestable, Premature optimization, Indescriptive naming, Duplication).

Ever heard of SOLID code? Probably: It is a term describing a collection of design principles for "good code" that was coined by Robert C. Martin (aka "uncle bob"), our beloved evangelist of clean code. [...] So, why not approach the problem from the other side for once? Looking at what makes up bad code.

He goes through each part of his STUPID acronym and talks about how it can hurt your code and a few alternatives to help make your application more flexible and easier to maintain in the long run. He also mentions GRASP (General Responsibility Assignment Software Principles), another set of good practices to follow, some similar to SOLID, that can make your app better.

In your development time, you might have heard of the SOLID development design principles that aim to keep you and your application well structured and on track. If you haven't had the time to learn much about them, you should consider this new post from Pim Elshoff that briefly covers each principle (with some code examples along the way).

Oh how we love acronyms. We've discussed a lot about writing a class, but we haven't talked about writing classes yet. How do you know if your solution is right? It is not enough to have a working program. SOLID is a set of principles that define severable measurable properties your architecture should have at least, in order to be dubbed right.

He goes through each of the principles (single responsibility principle, Liskov substitution principle, etc) and gives a summary statement, a definition and code illustrating it in use. The examples aren't all based on the same code as implementing all of these principles at once as been found to be difficult. He also includes another principle to keep in mind - the "Law of Demeter" dealing with calling scope of properties and methods.

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.

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.

On the Zend Developer Zone there's a recent post from Keith Casey about some of the basics of good OOP design, specifically in following the SOLID principles - a set of five guidelines that make code easier to manage and maintain over time.

As much as we're like to believe that "loose coupling, high cohesion" is enough, when you actually dive into the concept, you find that it's more descriptive than prescriptive. If you want to know how to actually apply these to your day to day development, you have to get into the SOLID principles which describes the five tangible aspects that "good" OO design should contain.

He goes through each of the five principles in the list, describing what they are and, for some, including a bit of sample code to make the point clearer:

• Single Responsibility Principle (SRP)
• Open/Closed Principle (OCP)
• Liskov Substitution Principle (LSP)
• Interface Segregation Principle (ISP)
• Dependency Inversion Principle (DIP)

On DZone.com there's a recent article from Giorgio Sironi about the SOLID set of principles for software development (more on those here) and how some related principles can be applied to namespaced code in PHP.

While studying for the advanced software engineering exam at PoliMi, I discovered there is also a set of principles akin to SOLID for the design of packages, and not only of classes and interfaces. Uncle Bob published them after the SOLID series. Note that package here can be intended as a zip or any deliverable binary unit, not necessarily as a PHP namespace or Java package, or a source folder. [...] In fact, I think that PHP namespaces will play the role of packages soon, as they provide a mechanism for encapsulation: use statements are not necessary when you refer to entities in the same namespace, just like java imports.

These three additional principles (CCA) are:

• CRP: Common Reuse Princple
• CCP: Common Closure Principle
• ADP: Acyclic Dependencies Principle

Check out the rest of the article for their full descriptions.

On his blog today, Marc Gear asks if developing PHP makes for a solid job prospect for the future:

Good developers who know and want to work in PHP are hard to come by. Consider that perhaps PHP is so popular because it does some jobs really well. [...] To me, [Terry's quote] says that PHP is a pretty good scripting language to be getting stuck into, that its something that you should be using if you want to develop web applications that are used by hundreds of thousands of users across the world.

He points out some developers that are almost ashamed for knowing PHP, thinking that it's a "low level" sort of language that doesn't really count in a world of Javas and .NETs. Too bad they're apparently oblivious to the high quality, enterprise level applications that are developed with it and use it every day. Shame to be missing out on that because of some silly personal opinions...