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.

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.

The single responsibility principle isn't all that hard to explain. It states that an object should do one thing, and one thing only. [...] A responsibility is a reason to change, and a class should only have one of those. Now all of this may sound abstract and since the objective of this series is to avoid just that we'll just dive into the why now.

He includes some sample code to illustrate, going with an active record implementation, some of the problems that come with a typical setup including issues with unit testing, bad practice of using the data store directly, etc. He shows a refactored code example that splits out the functionality previously all in the one class ("Bike") into three different ones - one is the normal Bike object, another compares the Bikes and the third works with the data store to handle the CRUD for the objects.

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

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.

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

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.

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.

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.

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.