L is for the Liskov Substitution Principle

-

The "L" in SOLID stands for the Liskov Substitution Principle. In my opinion, this has the most complicated definition, but the most obvious implementation, you're probably doing this without thinking about it.

This principle is named after Barbara Liskov, who defined it in 1988 as:

What is wanted here is something like the following substitution property:
If for each object o1 of type S there is an object o2 of type T such that for all
programs P defined in terms of T, the behaviour of P is unchanged when o1 is
substituted for o2 then S is a subtype of T.

Eh?

Derived classes must be substitutable for their base classes.

In my mind, this is one of the most fundamental principles of Object Oriented Programming? Definitely a staple when learning Java at University (I certainly remember this. "Dog and Cat are both types of Animal …").

Dependency injection frameworks put this into practise by supplying an implementation of the base class at run time that can just as easily be changed without any impact on the rest of your loosely coupled code.

Popular posts from this blog

I is for the Interface Segregation Principle

-
The "I" in SOLID stands for Interface Segregation Principle. It's more of a mouthful to say than it is to understand. It states : Clients should not be forced to depend upon interfaces that they do not use. Succinct right? i.e. Keep your interfaces as small and modular as possible. It maximizes their potential for reuse and prevents clients/end users from depending upon functions/methods they don’t really need.
Read more

S is for the Single Responsibility Principle

-
The "S" in SOLID stands for Single Responsibility Principle, and it’s probably the principle that gets the most bad press. It states that each class should have just one responsibility. My take on this is that this principle is another way of saying Keep It Simple Stupid (KISS). To quote Robert Martin himself : A class should have one, and only one, reason to change. One of Uncle Bob's favourite examples is "an “Employee” class that calculates the pay and saves the employee data to a persistence store. If there's a change required in how pay is calculated, the class will have to be changed. If the DBA makes some changes to the database schema, the class will probably have to change as well." Here the "Employee" class has two responsibilities which violates the SRP. One is business logic related and the other data infrastructure related. According to the Single Responsibility Principle, these concerns shouldn’t reside in th
Read more