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 this principle good practice. Can someone explain this to me? Thanks
Subclasses overriding methods in the base class are totally allowed by the Liskov Substituion Principle.
This might be simplifying it too much, but I remember it as "a subclass should require nothing more and promise nothing less"
If a client is using a superclass ABC with a method something(int i), then the client should be able to substitute any subclass of ABC without problems. Instead of thinking about this in terms of variable types, perhaps think about it in terms of preconditions and postconditions.
If our something() method in the ABC base class above has a relaxed precondition that permits any integer, then all subclasses of ABC must also permit any integer. A subclass GreenABC is not allowed to add an additional precondition to the something() method that requires the parameter to be a positive integer. This would violate the Liskov Substitution Principle (i.e., requiring more). Thus if a client is using subclass BlueABC and passing negative integers to something() the client won't break if we need to switch to GreenABC.
In reverse, if the base ABC class something() method has a postcondition - such as guaranteeing it will never return a value of zero - then all subclasses must also obey that same postcondition or they violate the Liskov Substitution Principle (i.e., promising less).
I hope this helps.
There is one popular example which says if it swims like a duck, quack likes a duck but requires batteries, then it breaks Liskov Substitution Principle.
Put it simply, you have a base Duck class which is being used by someone. Then you add hierarchy by introduction PlasticDuck with same overridden behaviors (like swimming, quacking etc.) as of a Duck but requires batteries to simulate those behaviors. This essentially means that you are introducing an extra pre-condition to the behavior of Sub Class to require batteries to do the same behavior that was earlier done by the Base Duck class without batteries. This might catch the consumer of your Duck class by surprise and might break the functionality built around the expected behavior of Base Duck class.
Here is a good link - http://lassala.net/2010/11/04/a-good-example-of-liskov-substitution-principle/
No, it tells that you should be able to use derived class in the same way as its base. There're many ways you can override a method without breaking this. A simple example, GetHashCode() in C# is in base for ALL classes, and still ALL of them can be used as "object" to calculate the hash code. A classic example of breaking the rule, as far as I remember, is derivin Square from Rectangle, since Square can't have both Width and Height - because setting one would change another and thus it's no more conforms to Rectangle rules. You can, however, still have base Shape with .GetSize() since ALL shapes can do this - and thus any derived shape can be substituted and used as Shape.
Overriding breaks Liskov Substitution Principle if you change any behavior defined by a base method. Which means that:
The weakest precondition for a
child method should be not stronger
than for the base method.
A postcondition for the child method
implies a postcondition for the
parent method. Where a postcondition
is formed by: a) all side
effects caused by a method execution and b)
type and value of a returned expression.
From these two requirements you can imply that any new functionality in a child method that does not affect what is expected from a super method does not violate the principle. These conditions allow you to use a subclass instance where a superclass instance is required.
If these rules are not obeyed a class violates LSP. A classical example is the following hierarchy: class Point(x,y), class ColoredPoint(x,y,color) that extends Point(x,y) and overridden method equals(obj) in ColoredPoint that reflects equality by color. Now if one have an instance of Set<Point> he can assume that two points with the same coordinates are equal in this set. Which is not the case with the overridden method equals and, in general, there is just no way to extend an instantiable class and add an aspect used in equals method without breaking LSP.
Thus every time you break this principle you implicitly introduce a potential bug that reveals when invariant for a parent class that is expected by the code is not satisfied. However, in real world often there is no obvious design solution that does not violate LSP, so one can use, for example, #ViolatesLSP class annotation to warn a client that it is not safe to use class instances in a polymorphic set or in any other kind of cases that rely on the Liskov substitution principle.
I think that you're literally correct in the way you describe the principle and only overriding pure virtual, or abstract methods will ensure that you don't violate it.
However, if you look at the principle from a client's point of view, that is, a method that takes a reference to the base class. If this method cannot tell (and certainly does not attempt to and does not need to find out) the class of any instance that is passed in, then you are also not violating the principle. So it may not matter that you override a base class method (some sorts of decorators might do this, calling the base class method in the process).
If a client seems to need to find out the class of an instance passed in, then you're in for a maintenance nightmare, as you should really just be adding new classes as part of your maintenance effort, not modifying an existing routine. (see also OCP)
The original principle:
"What is wanted here is something like the following substitution property: If for each object o1 of type S there is an object o2 of type T such that for all programs P defined in terms of T, the behavior of P is unchanged when o1 is substituted for o2 then S is a subtype of T.".
Barbara Liskov, 1987
The word is behavior. The "preconditions and postconditions" understanding is useful for a good design but is not related to LSP.
Let's check this summary of "preconditions and postconditions" theory:
Don’t implement any stricter validation rules on input parameters than implemented by the parent class.
Apply at the least the same rules to all output parameters as applied by the parent class.
An indication that it has nothing to do with LSP is: what about VOID methods? VOID does not have OUTPUT parameters. How could this rule be applied to VOID methods? How, according to this rule, could we guarantee to be complying with LSP in VOID methods?
LSP refers to Behavior. When a subclass inherits from a superclass and you have to use some trick to make this work, and the result change the behavior of the program you are breaking LSP.
LSP is about behaviour and the clasic example of Square x Rectangle help us to understand. In fact is the example used by Uncle Bob.
The you inherit Square from Rectangle and overrides SetHeight and SetWidth to force Square act as a Square even if it's a rectangle (by inheritance).
When the user calls SetHeight do not expect Width change.... but will change and this change the expected behavior and break LSP.
This is the problem with Virtuals x LSP
Related
From Wikipedia,
Liskov's notion of a behavioral subtype defines a notion of
substitutability for objects; that is, if S is a subtype of T, then
objects of type T in a program may be replaced with objects of type S
without altering any of the desirable properties of that program (e.g.
correctness).
Suppose the following class hierarchy:
The base abstract class - AnimalWithFur. It has a read-only property furColor that is overridden in successors.
Base class's successor - Cat, which overrides furColor and returns gray.
Cat's successor - Tiger, which overrides furColor and returns striped.
Then we declare a method with an argument of type Cat (not AnimalWithFur).
Is sending a Tiger instance to that method a violation of the L in SOLID?
Strictly speaking, yes. The wiki article summation of Liskov says:
"...in a program...without altering any of the desirable properties of that program"
If you go back to the original paper by Barbara Liskov, it's literally stricter in its wording, 3.3.
Type Hierarchy:
If for each object o1 of type S there is an object o2 of type T such that for all programs P defined in terms of T, the behavior of P is unchanged when o1 is substituted for o2
(Empahsis mine)
So if you replace an instance of Cat with another instance that does something different, i.e. returning stripped not grey, then that is a Liskov violation in the original sense, because a program could be easily defined that relies on the color being grey, here:
program(Cat c){
println(c.furColor);
}
The behaviour of that program will change if you pass it a Tiger in place of a Cat.
However, in the normal way LSP is applied, it is not a violation if you did not add extra preconditions or postconditions. This is a more practical, less academic definition as people accept that when replacing an instance of one concrete type with another you do intend to change the behaviour of the program while maintaining desirable properties of that program. So presuming the client code can handle stripped like any other colour, and grey was not required for a "desirable" property of the program then it does not violate.
Short answer: not necessarily. I'd have said not with the information you've given. The key, for me, is that you don't say what the imagined new method is supposed to do.
You might consider the behaviour that you're requiring in your new method to be more important than the concern of a class hierarchy.
One way to do this is to define an interface for the behaviour your new method needs from the passed in instance / argument.
Then whichever class you might want to pass into that method can implement that interface and you break apart the concern of an inheritance hierarchy and move to being concerned with consistency of behaviour.
Your question nicely describe why to use class composition instead of class inheritance. Firstly, your code is illogical - Tiger is not a Cat in your sense, Tiger is one of Cats family. From code point of view, it is bad design to override and totally replace the behavior of parent class, this is actually liskov substitution violation - your Cat class means defined cat with some concrete color, and application expects to work with it respectively, but you are overriding it with inconsistent type and change the behavior.
If you would describe types hierarchy correctly, you would have abstract type Cat without furColor implemented, and types Tiger and HomeCat, but HomeCat could have different color, isn't?
If you want to have trivial example of LS violation, e.g.:
You are extending List interface with custom implementation, returning size always 10, but with different count of objects inside. Each normal application expects to work with list using for statement, but will have unpredictable behavior because you've broken LS principle, and List object does not behave as it is expected.
I am studying liskov substitution principle. It says sub classes should be proper replacement for the base classes.
I read an example which I found at various places in the internet. A class Rectangle.java with height, width and their setter and getter methods. A class Square.java which requires only one attribute i.e length. If we have Square.java extending Rectangle.java then this is an violation of this principle. This is because the users of Rectangle.java expect width not to get affected if only height is modified and vice-versa.
My doubts:
The situations we see where methods are just overridden with empty open and close braces in order to prevent the execution of default code written in the base class. Are such cases violation of this principle ?
This principle also says inheritance should not be used just for reusing the code. Does in case as below it is a bad practice and is this a violation of this principle ?
If a class Window.java is available from some Graphic library. Suppose it has all the code necessary to draw a window. Also suppose it has a toolbar when it is used and drawn. If the requirement is to create a window without toolbar.
Simply Creating a WindowWithoutToolBar.java extending Window.java and
overriding the drawToolBarMethod() and leaving it with empty body
solves the purpose.[May be just create toolbar and not draw it so as to avoid any exceptions occurring from other methods trying to access toolbar object] Is this a bad practice ?
Creating a whole new Window class without toolbar would have required to rewrite all the code already written in Window.java.
In case of Numbers, If we have a class Integer.java with code in it for various arithmetic operations that can be done with an integer like squaring etc. If we have later need of NaturalNumber.java we can easily extend it from existing Integer.java and add checks to take only positive integers as input.
Now if we need AbsoluteNumber.java then in case we extend it from
Integer.java does this violates this principle (in case Integer.java
has some method as getValueAfterMultiplyByNegativeOne()) ?
Please provide your valuable feedback.
Regards,
Krishna Kumar
Interesting question.
As far as I understand, it would not be a violation iif leaving the method empty does not change the expected behaviour of that type. Basically, it strengthens the sub-typing requirements by not only respond to "a Square is a Rectangle", but also that its whole interface yields the same behaviour. For instance, what you mentioned about setting a rectangle's width should not affect its height.
Definitely inheritance should not be used only for code re-use. If it actually applies to all possible sub-types, then go ahead, you'll probably be fine. If it only applies to a sub-set of them, you'll find yourself constantly overriding methods and, at the end of the day, writing more code.
You can instead encapsulate that common code into meaningful components that can then be used within your classes by means of composition.
In the case of Numbers, I think you're parting from the wrong premise. I would not extend Integer class to implement Naturals. Think when subtracting two naturals, where the second is higher than the first one: ie. 3 - 5. In here, you'd need to make a choice, which would be either to throw an Exception or to return something that is no longer a Natural. A different approach would be to extend an abstract Number class, where you could define a set of methods as follows:
abstract class Number {
public abstract Number sum(Number other);
public abstract Number subtract(Number other);
public abstract Number multiply(Number other);
public abstract Number divide(Number other);
}
This implementation would not be perfect, since it would require some assumptions to be made, like what implicit conversions (casts) to do in case you're operating upon different types. But in this case, it'd allow you to apply the Liskov Substitution principle a bit more freely.
I would say it is not a violation. I think it would be a violation if you throw an exception like
throw new Exception('Not implemented');
When this exception is not expected / documented in the base class / interface.
That means if you substitute an existing class with yours, it would throw an exception, where base class did not tell, and code could break, because someone might not implement a try catch block around.
Inheritance "should" not be used in most cases to reuse code. Composition is the way to go. I would say it is a bad practice. Just my thoughts.
I have a base class which adds some functionality to a number of derived classes in my app.
One of these features is only used by some subclasses.
Currently I'm using a method which returns a BOOL which defaults to NO to "short-circuit" this feature. Subclasses which want the feature must override this method and return YES.
This feature is only useful if you've also overridden at least one of two other methods.
I'd prefer to use class_copyMethodList to determine if the subclass implemented either of these two methods (instead of using the method which returns a BOOL).
What barriers/roadblocks/cons to this approach should I be aware of? Is there a standard implementation of this idiom which I can use?
If I may suggest an alternative approach, have you considered using -instanceMethodForSelector on the relevant subclass instance and comparing to the result on the base class?
That method returns an IMP, which is a C function pointer to the implementation for the given selector. So if the subclass has a different implementation from the base class, it'll return a different IMP.
EDIT: as discussed in the comments below, a further alternative is to declare a formal protocol that the sub classes may implement, and to use NSObject's -conformsToProtocol: to determine whether the protocol is implemented. Since conformsToProtocol returns whether the class has declared support for the protocol (in its #interface via the angle brackets syntax), that's a lot like adding a custom BOOL method that defaults to returning NO but without the syntactic and semantic overhead of adopting your own ad hoc solution.
I have a base class which adds some functionality to a number of derived classes in my app.
This sentence should cause you to rethink your design. A base class should never do anything to derived classes. It should be ignorant of its subclasses. (Class Clusters notwithstanding. That's a separate design approach and require the superclass to be aware in the construction, making it the Factory pattern, which is fine.)
One of these features is only used by some subclasses.
This is a strong indication of a "Square/Rectangle" mistake. In OOP (forget ObjC, this is just CS theory), a square is not a rectangle. You need to ensure that your types conform to Liskov's Substitution Principle. Again, this has nothing to do with any particular language; it's true of all OOP design. It may seem very "theoretical" but it will seriously screw up your implementation if you fail LSP, and you will chase subtle bugs for much longer than you like.
The pattern you probably want here is Decorator rather than subclassing. If you have some special functionality that exists on some classes, you want to encapsulate that functionality into a separate object and attach it to subclasses where it makes sense. Another possible pattern is Strategy (which is generally implemented as a "delegate" in ObjC, which is another way of thinking about Decorator). The point is that you don't want logic in the superclass that is only applicable to some subclasses. You want to put that logic into something that only exists in the appropriate subclasses.
If all of those things fail you, then I strongly recommend a simple (BOOL) function over anything that introspects the method implementations. That way is fragile because it relies on ever-deeper implementation details. respondsToSelector: is definitely better than testing instanceMethodForSelector:.
I'm trying to solve a design issue using inheritance based polymorphism and dynamic binding. I have an abstract superclass and two subclasses. The superclass contains common behaviour. SubClassA and SubClassB define some different methods:
SubClassA defines a method performTransform(), but SubClassB does not.
So the following example
1 var v:SuperClass;
2 var b:SubClassB = new SubClassB();
3 v = b;
4 v.performTransform();
would cause a compile error on line 4 as performTransform() is not defined in the superclass. We can get it to compile by casting...
(v as SubClassA).performTransform();
however, this will cause a runtime exception to be thrown as v is actually an instance of SubClassB, which also does not define performTransform()
So we can get around that by testing the type of an object before casting it:
if( typeof v == SubClassA)
{
(cast v to SubClassA).performTransform();
}
That will ensure that we only call performTransform() on v's that are instances of SubClassA. That's a pretty inelegant solution to my eyes, but at least its safe. I have used interface based polymorphism (interface meaning
a type that can't
be instantiated and defines the API of classes that implement it) in the past, but that also feels clunky. For the above case, if SubClassA and SubClassB implemented ISuperClass
that defined performTransform, then they would both have to implement performTransform(). If SubClassB had no real need for a performTransform() you would have to implement an empty function.
There must be a design pattern out there that addresses the issue.
My immediate comment is that your object modelling is wrong. Why treat SubClassA as a SuperClass (is-a relationship), when I would suggest that it's not.
You could implement a dummy performTransform() that does absolutely nothing in its base instance, and is overridden in SubClassA. But I'm still concerned that on one hand you're treating all these objects (SubClassA, SubClassB) as the same thing, and then wanting to treat them differently depending on their real implementation, rather than the interface they present.
Assuming you are using a strongly-typed language, which your question seems to indicate...
There is no design pattern to work around this, because this is the intended behavior.
In your definition, performTransform belongs only to SubClassA. Thus, to be able to invoke performTransform on an object, the object must be of type SubClassA (or a subtype of SubClassA.
Invoking performTransform on a SuperClass does not make sense because not every instance of SuperClass defines this method.
Downcasting from a SuperClass to a SubClassA should certainly throw an error if the instance is not a SubClassA - this should be obvious.
So, you must either change your definitions such that performTransform belongs to SuperClass (in which case, as you said, every instance of type SuperClass would need to have some implementation for the method, even an empty one) or you must make sure that you are only invoking methods on types that define them.
I'm not so sure it requires a pattern to solve but instead just a small redesign. If it makes sense for anything to call performTransform is should be in the superclass as a virtual method and overridden in the subclasses.
So the superclass defines the flow from an abstract viewpoint and the subclasses implement them appropriately. In your case, the simplest options are to either just leave performTransform empty in the superclass or implement it as an empty method in the subclass that doesn't require it (when you mix this approach with a short comment, you get a more maintainable system IMO).
The closest pattern I can think of for this is the Null Object pattern where this performTransform method is just a dummy function to preserve compatibility but perform no actual task.
Just because you say your bicycle is a car doesn't mean there's a place to put gas in it. The whole point of polymorphism is to let you think of things as the super class - these are all bank accounts, these are all shapes, to use the classic examples - and not get caught up in what they really are. Sometimes the subclasses add capability. In many cases that capability is used in the specific implementations in each subclass. So to use your names, some method Adjust() that is in the signature of SuperClass is implemented (differently) in SubClassA and SubClassB. The SubClassA version calls its own performTransform as part of the process and we all live happily ever after. The minute some code needs to decide whether to call performTransform or not, you're not just thinking of it as a SuperClass any more. That's not necessarily something that needs to be solved, it's just what is.
It Would be better to have the call to performTransform() in a method that only takes type SubClassB as a parameter - at least you wouldn't have to do type checking then.
On saying that, if your having this problem at all it may suggest that inheritance may not be the best solution - composition may be a better way to approach the problem.
If I have an abstract class and derived classes of that class, am I correct that, according to good and practical design practice, that the derived classes should not provide extra public methods (they should only implement abstract classes and optionally override parent methods)?
Furthermore, is it acceptable practice to have a different constructor method signature for each derived class?
Personally, I see no problem with either.
As for extra public methods on derived classes:
There is limited usefulness in this, in many cases. The extra methods will not be usable when the class has been cast or set to an reference to the base class, which severely limits usefulness of this practice. That being said, there isn't anything particularly wrong with this approach. Subclasses are meant to add specific behavior - sometimes, in a class hierarchy, there is new behavior in a subclass that isn't appropriate for the base class. If the subclass is going to be used frequently on its own, it seems perfectly reasonable for the extra behavior to be modeled in the methods.
As for constructor signatures -
I see no problem with this either. Subclasses often need more information to be put into a usable state than the abstract class. That being said, I typically make sure to implement every constructor in the base class, plus add the new parameters required for the subclass.
That being said:
Unless there is good reason, I'd avoid having a subclass constructor with fewer parameters than the base class ... why would I be able to specify something on a more generic case and not the specific case? I find that it's usually confusing when subclasses have completely different construction options than their base classes.
This is the beauty of derived classes.
While a Pen class might have a write() function, a RetractablePen class which extends Pen might also have a retractPoint() function.
When you extend a class it means -- literally -- extending the functionality of it.
It's fine in general.
What you want to avoid is using the specific in the generic. i.e.
foreach(Animal a in myFarm.Animals)
{
a.Feed();
// this is a bit grim
if( a is Horse )
{
((Horse)a).CleanStable();
}
}
So it's not the act of adding the public method but rather where you call them from.
It's perfectly acceptable to add additional public methods to your derived classes. It's also perfectly acceptable to give them different contructors. (In fact, this is quite common.)
No, it's perfectly reasonable (and sometimes very necessary by design) to add additional public methods. Consider the (completely contrived) situation of a Shape abstract base class that has a Location member and a Size method. When you derive Polygon from Shape, for example, you may want to add a public method called GetNumberOfSides(), for example; but you don't want to have that when you derive Circle from Shape.
In the same way, the derived types may have very different construction requirements; it's not really possible to know what all the requirements may be when defining the abstract base class, so feel free to have differing signatures. Just because your dervied types will be polymorphic to the abstract base class doesn't mean that that base class imposes strict limitations on how you can implement the abstractions defined in that base class; you're free to pretty much do it however you want.
If you respect the Liskov substitution principle, you can do what you want.
Of course, add a method to a derived class doesn't violate the principle at all.
the derived classes should not provide extra public methods
Can a dog do things that an animal can't?
Furthermore, is it acceptable practice to have a different constructor method signature for each derived class?
There's no problem here. Derived types are not required to match constructor signatures of their siblings or parents.
It is not only acceptable, it is often necessary for the constructors to be different. For example, if we have an (immutable) Rectangle class and extend it with an (immutable) Square, the constructor of Square should be (to use Java for the moment)
public Square(double size)
while the constructor of Rectangle would be
public Rectangle(double width, double height)
What does need to happen is that the subclass constructor should call some appropriate superclass constructor.
As to extra public methods, it may depend on the use. For the Square case, I would not add any extra methods. In Java, however, there is a subclass PrintWriter of Writer
whose purpose is to add some convenience methods. In this case I think it okay (Java certainly has some bad examples but I don't think this is one of them). I would also expect the possibility of some extra methods for container/subpart types.
What you shouldn't do is change the super classes methods in a way that violates the expectations of the super class.