Monica Shiralkar wrote:But doesnt this happen all time time? e.g a Dog is always an animal. A ford is always a car
Junilu Lacar wrote:
.
Campbell Ritchie wrote:You try writing a version of that method that will take any kind of Animal. Say what assumptions you are making.
What do you think? Take it for a walk.Monica Shiralkar wrote:. . . do what after that ?
Campbell Ritchie wrote:
What do you think? Take it for a walk.Monica Shiralkar wrote:. . . do what after that ?
Everybody knows that octopuses are more intelligent than dogs, but I have never seen anybody taking their pet octopus for a walk round the park. But octopuses can walk; I have seen one on YouTube which escaped itscagetank at an aquarium at Plymouth and managed to walk to the harbour, where it presumably found more water.
In OO that would translate asJunilu Lacar wrote:. . . . If the superclass accepts one kind of input, its subclasses should also accept the same input. . . . .
. . . or more input. As far as I am concerned, if the overriding method would throw an exception for input which the overridden method would accept, that is incorrect overriding. It is permissible for the overriding method to accept more inputs than the overridden method. There is a description in Object‑Oriented Software Construction by Bertrand Meyer, but I think he doesn't say, ”Liskov.” Can't fid the page in my copy; sorry.Junilu Lacar wrote:. . . . If the overridden method accepts one kind of input, itsoverriding methods should also accept the same input. . . . .
Junilu Lacar wrote:This would be a more reasonable example:
.
If you create some subclass of Animal that causes exercise() to fail when passed an instance of that subclass while others succeed
Monica Shiralkar wrote:Is it also possible to violate this principle in this example by using a case where no exception is thrown?
Junilu Lacar wrote:Sure. Let's say an Animal defines "walking" to be any movement that is done at a rate of say 20 to 40 paces per minute and "running" to be any movement done at a rate that is greater than 40 and less than 120 paces per minute.
Junilu Lacar wrote: What part of "code that uses references to a superclass should still work correctly when operating on instances of a subclass" don't you understand?
Any subclass must always obey the principle that a subclass IS‑A superclass. An overriding method must always obey the specification given by the overridden method. Any changes must follow those constraints.Both those methods calculate pay (without calculating taxes) and may or may not throw such an exception. It would be wrong to implement that abstract method to calculate taxes. It would be all right to pass 1000000 hours to one overriding version because it ignores that parameter anyway. It is necessary to explain what the method does (=documentation comments) in order to allow it to be overridden. I shall let you guess what the last change I made to the documentation comments was, and how that causes both implementations to break the LSP. Also tell me what I put in the documentation comments that restrains the code in the future.Monica Shiralkar wrote:. . . any subclass in Java has the right to override and change the implementation. . . . .
Monica Shiralkar wrote:Does that mean that everytime overriding takes place (by the sub class ), Liskov principle gets violated.
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.
Monica Shiralkar wrote:I wonder why this does not get mentioned in the documentation of Overriding that you can give any new implementation but without breaking Liskov principle.
While implementing, where exactly can one check the contract of the original method?
Monica Shiralkar wrote:I wonder why this does not get mentioned in the documentation of Overriding that you can give any new implementation but without breaking Liskov principle.
While implementing, where exactly can one check the contract of the original method?
Wouldn't you also say that the classes involved must honour that guarantee?Stephan van Hulst wrote:. . . if a method or class contract guarantees something . . . then that guarantee must also be made by subclasses. . . .
Monica Shiralkar wrote:so in the comments over the method and class.
Campbell Ritchie wrote:Wouldn't you also say that the classes involved must honour that guarantee?
Junilu Lacar wrote:
In your example, if the contract defined by the makeSound() method in the superclass states that it will display a String then all subclasses must display a String if they override makeSound(). If there is a subclass that does not display a String but say only plays a sound file instead, then it has broken the contract. In that case, LSP will have been violated.
No, that wasn't what I meant; I was thinking about callees only.Stephan van Hulst wrote:. . . If you mean calling classes/methods, then no. . . . .
Monica Shiralkar wrote:
But will it give me error? What problem exactly will I encounter during runtime at line
pie. tiny ad:
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop
https://coderanch.com/wiki/718759/books/Building-World-Backyard-Paul-Wheaton
|