![]() ![]() This means that the subtype is not entirely substitutable. Public startEngine() So we throw an exception in the "startEngine" method in the subtype "Bicycle" and this is the problem. But because the Bicycle class doesn't implement the "startEngine" method, what we do is that we throw an exception in the implementation of a "startEngine" method in the Bicycle class. But for some odd reason, we really needed Bicycle class to inherit directly from the Vehicle class. This method is supposed to mutate the "engineStarted" property of the concrete Vehicle. So let's say that the Vehicle base class states that the class needs to have or that the object needs to have a method called "startEngine". That's what you were forced to do because of some bad design. Let's say you have a "Vehicle" class which is a base class, and you inherit it in classes "Bicycle" and "Car". Let's take a simple example of violating the LSP. Postconditions and invariants in the subtype must be the same or stronger than in the base types. Preconditions in the subtype must be the same or weaker. So here is how it relates to the Liskov Substitution Principle. And invariants are what has to be true at all times of the method execution. The postcondition is whatever must be true when the method has been called and when all statements from the method were executed. Postconditions are sort of on the other end. Whatever is stated in the preconditions must be true. The simplified definition for preconditions is that they are sort of the entry conditions for the method. ![]() To discuss this topic in more details we will talk about such terms as Preconditions, Postconditions, and Invariants. It just means that as soon as you are inheriting from the base class in a way that makes the subclass not substitutable for this particular base class then you're breaking the Liskov substitution principle. So, in every place where you're using the base type, you should be able to swap that instance for an instance of the subtype without causing any unwanted behavior in the program. So the principle states that if you have a base type and you have a subtype, in other words, if you have a base class and you have a class inheriting from that base class then the subclass should be substitutable for the base class at any point in the program. In fact, the principle is actually really really simple. Liskov substitution principle is the L in the SOLID object-oriented design principles. Let's talk about the Liskov substitution principle. You can scroll down to find a link to the original video talk on this topic. This post does not contain unique ideas, this is just my understanding of a good video I recently found on youtube. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |