Liskov Substituition Principle Explained - SOLID Design Principles | Example Code | InterviewDOT скачать в хорошем качестве

Liskov Substituition Principle Explained - SOLID Design Principles | Example Code | InterviewDOT

Click here -    / @interviewdot   to get notifications. Tamil Liskov Substituition Principle Explained - SOLID Design Principles | InterviewDOT Definition of the Liskov Substitution Principle The Liskov Substitution principle was introduced by Barbara Liskov in her conference keynote “Data abstraction” in 1987. A few years later, she published a paper with Jeanette Wing in which they defined the principle as: Let Φ(x) be a property provable about objects x of type T. Then Φ(y) should be true for objects y of type S where S is a subtype of T. OK, let’s be honest. Such a scientific definition might be necessary, but it doesn’t help a lot in our daily work as software developers. So, what does it mean for our code? The Liskov Substitution Principle in practical software development The principle defines that objects of a superclass shall be replaceable with objects of its subclasses without breaking the application. That requires the objects of your subclasses to behave in the same way as the objects of your superclass. You can achieve that by following a few rules, which are pretty similar to the design by contract concept defined by Bertrand Meyer. An overridden method of a subclass needs to accept the same input parameter values as the method of the superclass. That means you can implement less restrictive validation rules, but you are not allowed to enforce stricter ones in your subclass. Otherwise, any code that calls this method on an object of the superclass might cause an exception, if it gets called with an object of the subclass. Similar rules apply to the return value of the method. The return value of a method of the subclass needs to comply with the same rules as the return value of the method of the superclass. You can only decide to apply even stricter rules by returning a specific subclass of the defined return value, or by returning a subset of the valid return values of the superclass. The Liskov Substitution Principle (LSP): functions that use pointers to base classes must be able to use objects of derived classes without knowing it. The Liskov Substitution Principle is the L in SOLID object oriented design, and despite having one of the more intimidating sounding names of the 5 principles, it's actually pretty easy to wrap your head around. It's so simple, in fact, that you're going to understand it in about 3 minutes. What Is It? The LSP, in simple terms, states that objects of the same superclass should be able to be swapped with each other without breaking anything. If your code adheres to the Liskov Substitution Principle you have many benefits. These include: code re-usability, reduced coupling, and easier maintenance. Benefits This principle aims to keep functionality intact. It's main purpose is to guarantee that objects lower in a relational hierarchy can be treated as though they are objects higher in the hierarchy. Basically, any child class should be able to do anything the parent can do.