SOLID: The Liskov Substitution Principle (LSP)

After a week of holidays, here I am again, back to coding and learning. I really needed a rest but, on the other hand, after a couple of days, I was missing  my computer to bits.

¡Already the third letter of SOLID! Let's get into it.

This complex to understand principle can be described as follows: 

"If s is a subtype of t, then we should be able to substitute objects of type t by objects of type s  without altering the properties of the program."
 In other words, it is possible to substitute a given object with an object of a sub-class and expect it to react the same way and fulfill its contract.

But as usual, it is easier to understand if we have a look at a code snippet. Imagine our app currently sends all of our Notifications through Plain Text Email through SMTP.  Our code would look something like this:

<?php
$emailMessage = new EmailMessage('Laura', 'New Blog Post', 'Hi Laura, ...');
$smtp = new SMTPTransport ('smtp.example.com', 465);
$notifier = new Notifier();
$notifier->setTransport($smtp);
$notifier->send($emailMessage);

What happens if, in the future, we also send Emails containing HTML instead of plain text? We would only need to add subclasses and pass them to the Notifier (caller), as this is completely independent from EmailMessage and SMTPTransport classes. So, substituting the parent class EmailMessage by a child class HTMLEmailMessage extending EmailMessage. 

Again, it all comes down to set a hierarchy where we make a contract between the child and the parent. If we fulfill LSP, we will be able to extend the parent or replace it any of it's children without affecting the functionality as seen in the previous snippet.

Summarizing the SOLID principles reviewed till now, we could say:

  • Single-Responsibility Principle: allows us developing small classes with precisely delimited responsibilities
  • Liskov Substitution Principle: it allows us to use polymorphism in our code. Which means, if we write a function which takes a given argument, polymorphism allows us using any subtype of that argument without affecting the functionality of said method. 
  • Open-Closed Principle: the two previous principles are the key for this one, which allows us writing small classes with a solid hierarchy throughout our whole app.   
As usual, understanding each of the principles is not the most difficult part, but applying it. In my case, I try not to get crazy trying to use them in my code straight away. I've been developing an app, and at least for the MVP, I have learnt that the most important thing is making it work and then applying some make-up to make you feel proud of it and make it look professional. And, last of all, if you manage, apply some of the things you learn on the way. But if you don't,  I do encourage writing your own examples and testing them. Make them small and start abstracting the most simple concepts. And if this fails, read, read read. Read blogs, read manuals (though these sometimes leave you even more confussed), read forums, and find as many examples and snippets as you can, as one of them will make you finally understand the concept.

Happy week and happy coding everyone!
 

Comments

Post a Comment

Popular posts from this blog

SOLID: The Single-Responsibility Principle (SRP)

 This Object Oriented Programming principle states that each module or class should be responsible for only one part of the functionality.  By saying this, we are stating that each subsystem, module, class or function should have just one reason to change.  How do we accomplish this? By developing small service classes with enclosed objectives.  What is it that we want to accomplish through this strategy?   More cohesion and less resistance to change. Allow the composition of classes (or class injection) which deserves a extended post in this blog. Avoid duplicity and copy-pasting portions of code. Now, that seems fairly simple but, as with any theoretical principle, the problem is usually visualizing with an example what the theory is suggesting and, even more than that, in which cases should we apply this theory. Of course, it's not the same developing a small online shop for a cousin who produces and sells hand made costume jewelry, than developing  an a...
Read more

Symfony HTTP client

 I am currently developing a very simple app which offers you the possibility to create question-answer flipping cards, creating thus some kind of funny Trivia to practice on any topic you want to apply it to. As a user, you create first the question-aswear entities which also include  category field, and then you can practice them in the playground area, which shows you the question on a hoverable flipping card. It also offers you a textearea which disables 60 seconds after you start typing on it, so that you can write down your answer before actually flipping the card and getting to see the correct one.  In this app, though simple, I wanted to keep a client-web service architecture from the very beginning. The web client contains the views and communicates with the API, which contains the data through Ajax calls. This was working consistently so far. An example of the creation and saving of new question-answer items is: When I press on "Create new question" button, I am...
Read more

Inheritance: Abstract classes and interfaces

What is inheritance? It's a programming principle used in the PHP object model which allows a class (child) to inherit another class' (parent) protected or public methods, properties and constants, retaining the parent's original functionality, unless these are overriden by the child class. What is an abstract class? A class that contains at least one abstract method, which means only the signature of the method is defined. For example: abstract Class Parent { abstract protected function defineMyFunction (). } Class Child extends Parent {      protected function defineMyFunction () {           return "I am an abstract function in my Parent class" ;      } } As childish as this example might seem , it quite easily represents the aforementioned definition. When a  class (or child class) extends from an abstract class (or parent class), it must define all methods declared as abstract. In fact, if you are using an IDE...
Read more