liskov-substitution-principle

One of the rules that Liskov Substitution Principle imposes on method signature in derived class is: Contravariance of method arguments in the subtype. If I understood correctly, it is saying that the derived class's overridding function should allow contravariant arguments(Supertype arguments). But, I could'nt understand the reason behind this rule. Since LSP talks mostly about dynamically binding the types with there subtypes(rather than supertypes) in order to achieve abstraction, so allowing supertypes as the method arguments in derived class is quite confusing to me. My questions are :

Today somebody told me that interface implementation in C# is just "Can-Do" relationship, not "Is-A" relationship. This conflicts with my long-time believing in LSP(Liskov Substitution Principle). I always think that all inheritance should means "Is-A" relationship. So, If interface implementation is just a "Can-Do" relationship. What if there is a interface "IHuman" and "IEngineer", and one class "Programmer" inherits from "IHuman" & "IEngineer"? Surely, a "Programmer" Is A "IHuman" and A "IEngineer". If it is just "Can-Do" relationship, does it mean we cannot expect the "Programmer" instance

Use case: I'm using data templates to match a View to a ViewModel. Data templates work by inspecting the most derived type of the concrete type provided, and they don't look at what interfaces it provides, so I have to do this without interfaces. I'm simplifying the example here and leaving out NotifyPropertyChanged, etc., but in the real world, a View is going to bind to the Text property. For simplicity, imagine that a View with a TextBlock would bind to a ReadOnlyText and a View with a TextBox would bind to WritableText. class ReadOnlyText { private string text = string.Empty; public string

Consider this ruby example class Animal def walk # In our universe all animals walk, even whales puts "walking" end def run # Implementing to conform to LSP, even though only some animals run raise NotImplementedError end end class Cat < Animal def run # Dogs run differently, and Whales, can't run at all puts "running like a cat" end def sneer_majesticly # Only cats can do this. puts "meh" end end Does method sneer_majesticly violate LSP, being defined only on Cat, since this interfaces is not implemented nor needed on Animal? The Liskov Substitution Principle has nothing to do with classes.

I've read some of article about the practice that making Square an inheritance class of Rectangle class is a bad practice, saying it violate the LSP (Liskov substitution principle). I still don't get it, I made a example code in Ruby: class Rectangle attr_accessor :width, :height def initialize(width, height) @width = width @height = height end end class Square < Rectangle def initialize(length) super(length, length) end def width=(number) super(number) @height = number end def height=(number) super(number) @width = number end end s = Square.new(100) s.width = 50 puts s.height Could anyone

I am in a situation very similar to what Steve McConnell's in Code Complete has mentioned . Only that my problem is based of Vehicles and Trike happens to be on that by law falls in the category of Cars . Cars had four wheels until now . Any way my domain is unnecessarily complex so it is easy to stick with cats example below. Be suspicious of classes that override a routine and do nothing inside the derived routine This typically indicates an error in the design of the base class. For instance, suppose you have a class Cat and a routine Scratch() and suppose that you eventually find out that

My understanding of the Liskov substitution principle is that some property of the base class that is true or some implemented behaviour of the base class, should be true for the derived class as well. I guess this would mean when a method is defined in a base class, it should never be overrided in the derived class - since then substituting the base class instead of the derived class would give different results. I guess this would also mean, having (non-pure) virtual methods is a bad thing? I think I might have a wrong understanding of the principle. If I don't, I do not understand why is