Solid Part 3 - LSP (Liskov Substitution Principle)

The third part of SOLID is Liskov Substitution Principle (LSP), a scientific article created by Barbara Liskov in 1987.

The principle says "A base class can be replaced by the derived class". There are two questions to think  about when using the Liskov Principle:

1- Does the base class have useless behaviors for the derived class?

2- Is the external behavior changed when we replace the base class for the derived class?

If one of them is true, using Liskov Principle the relation of the base and derived classes is wrong.

When you are using inheritance if the derived class does not implement all the methods of the base class or part of the methods and attributes of the base class does not make sense for the derived class, according to LSP that inheritance is wrong and may bring future problems to the software. Imagine a software that you have to calculate discounts for new customers and for old customers:

Base CustomerClass

Derived PossibleCustomerClass

Let's see what happens when this code runs:

Console Application

When I run the code above in a Console Application I got the result:

Console Application Running

Oh it works fine, but if I replace Customer for PossibleCustomer?

Possible Customer 

The possible customers can not have a Register Date, when I run that code, I get this result:

PossibleCustomer Error

As we can see, the concept of inheritance can not be used only for reuse the code, the concept must be used only when makes sense the inheritance of characteristics and behaviors of the base class.

In general, when we use Open Closed Principle in our code, is easier to use LSP. 

When we will use inheritance, we must ask "Is the objectA an object of objectB?", for example "Is a dog an animal?" or "Is a chocolate a candy?" if the answer is true and the external behavior of the classes is the same, the derived class can use the behavior and characteristics of the base class.

In some cases, to use LSP we just have to implement the Interface Segregation Principle (ISP), but about that I will write next week!

Solid Part 2

Hello everybody, today I am going to continue the five parts about SOLID, and the part 2 is about Open/Closed Principle.

OCP - Open/Closed Principle

As the name suggests, a class must be open for extensions and closed for modifications, this can confuse you but it is very interesting! 

It means that the class can easily change their behavior without a change in their source code.That extension can be made by using inheritance, interface or composition.

This is very important when you are changing a class that works fine in production environment without the need of new unit tests, concern if the class will generate some bugs, unknown errors in stable parts of the code.
The concept of extension remember us the use o inheritance in OOP, the idea is when a class is working in production environment, the class changes only in a fix of development bugs or a change in model classes, for example, adding a new property but other changes  as new resources must be implemented as extension of that class, so this principle says that we should have so many abstractions among the software.

Let me exemplify for you, imagine that we have a class which calculates the interest for bank accounts, if we have two types of account the current account and the savings account our code will be that:

OCP Example

Ok, it works, but if we need to add another account type or make changes on the calculation? It is not cool to add a lot of IFs in our class, it will difficult some analisys and changes in our class and in a large class it can cause so many bugs. To put this class into the Open/Closed Principle we need to use that code:

Account class in OCP

With the code above we can implement new account types without a change in the Account class or the others account types, we just need create a new class inheriting from AccountOCP class and override the CalculateInterest method, so the class is Open for extensions and Closed for modifications and you do not need to change any code in any class when implement a new account type.