Liskov Substitution Priniciple

 Just some few points to get back to , since for some reason I keep on forgetting what its intention out of the 5 SOLID principles.

Historical intro: 
As per wikipedia it was introduced by Barbara Liskov  in a 1988 conference keynote that was titled Data abstraction and hierarchy.

It was defined as:

"Let {\displaystyle \phi (x)} Ø(x) be a property provable about objects {\displaystyle x}(x) of type T. Then {\displaystyle \phi (y)} Ø(y) should be true for objects {\displaystyle y} (y)  of type S where S is a subtype of T."

So to simplify it a little bit , x here is like an instance or an object of class of type T, this could be a User , Class or Employee Class,...etc.

Same Also goes for (y) , it can be an instance of a class of type S.

so what Liskov principal states here is that if a certain property/method  (Ø(x)) do exists in objects of type

T, then this exact same property/method has to be presented in objects of type (S) as well,  if  S is a subtype of T.

In Other words: we should be able to  replace objects of a parent class with objects of subclass without breaking the application.

I believe this is trying to make us think before using Inheritance , as in order not to break the Liskov Principle we need to make sure that all of the sub-classes have all the existing functionalities of their  parent class. So what usually happens is that we start with a general type and then as requirements change/become more clearer/ time pass we need to add some special cases , but what Liskov principle trying to tell us is to maintain the properties of the Parent general class with the more specific case , or should we do it in a different way altogether other than inheritance (an (is-a) relation), by using composition (a (has-a ) relation )for example which is BTW more flexible and less troublesome .  


I believe the most famous example is the Rectangle and Square ,where the rectangle is the Parent class while the square is the sub-class but if we are to use them interchangeably then the fact that a rectangle has his own width and height change independently of one another would be violated by the fact that a Square has his width and height set to the same value.


Some more examples can be found here :
Satckoverflow-Examples on Liskov Principle 

Comments

Post a Comment

Popular posts from this blog

Head First Architecture

Image
 I have found out that there is a new book that is under early release version on the O'reilly website  called Head First Architecture that is to follow on the great Head First series , as I have read the Head First Design patterns book and really liked it several years ago and the fact that Neal Ford  (One of the authors of Software Architecture An Engineering Approach) is one of the authors, I take a look on it and found that it really is adding a lot of value at least for me, so I am doing a brief summary of it in the next couple of posts hopefully. At first it draws an analogy between building houses and building software systems, in this analogy the building plan or the blueprint of houses is the equivalent of the software architecture, what might be the similar point between both: 1- Both specify the structure of the system, in the house case it defines the rooms, walls, stairs and floors, in the case of the software system it defines the databases, services, user-i...
Read more

Head First Architecture Chapter-3

Image
 This chapter is mainly about the fact that software architecture has a lot of tradeoffs. An Application Scenario: A scenario was given about an application for selling sneakers (this could be anything tbh), that helps people buy, sell, and trade collectible sneakers.  The initial architecture was simple a single service that responds to requests send by mobile app users. So there are 2 options we might get into the tradeoff between them , which are using queues or using topics for messaging : so we can do the tradeoff analysis for each approach of them: 1- Queue approach  Pros:  a- It is more secure as the publishing service is aware of the receivers as each new service would have a new queue and the publishing service would need to know about it to send to it. b- we can have a different format for each receiver. c- we can scale and monitor independently each queue.  2- Queue approach Cons: a- Higher degree of coupling which hurts extensibility. b- Require...
Read more

The Culture Map -Some notes

Image
 I have been reading over the last few days  a book titled the Culture Map, it is extremely amusing and a clear eye opener for me . It is about the different culture contexts and how they can affect us in the work environment , implicitly and unintentionally sometimes. This also does not mean to follow  the different stereotypes as people from same country can different traits for sure, but also the cultural effect can have huge impacts on behaviors for sure. The Book Defines 8 Scales /Measurements that are needed in any business environment and how the cultural differences might affect them. 1- Communication: Low Context vs High Context : There are some cultures that start any communication without suggestion that there is a common context between different parties , that is why they tend to clearly document every step and  leave no space for speculation those are low context style of communication. While there are some other cultures that tend to assume an existing...
Read more