Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

Say I have:

interface Thing
{
    GetThing();
}

class FastThing : Thing 
{
    public int GetThing()
    {
        return 1;
    }
}

class SlowThing : Thing
{
    public int GetThing()
    {
        return GetThingFromDatabase();
    }
}

Is this a violation of the Liskov Substitution Principle?

share|improve this question
    
GetThingFromDatabase() is not slow enough to make this controversial. Factor4096BitPublicKey();return 1; would make things a bit more interesting. –  Patrick Feb 10 '13 at 9:46
    
1  
If you replace FastThing with SlowThing, the LSP does not apply. If you add a comment to Thing::GetThing which says "Is very fast", the question can be discussed. –  Arian Nov 10 '13 at 20:08

6 Answers 6

up vote 11 down vote accepted

That really depends. Some interfaces have, for example, complexity constraints (these obviously can't be programmatically enforced). The most basic case is "GetThing() gives an int- i.e., it halts", in which case, the answer would be "No"- both versions of GetThing() halt and return an int.

But many interfaces have implied or expressly stated performance guarantees, either in complexity or in flat time. For example, in the C++ Standard, it's illegal to implement the library with a blocking call except where the Standard expressly permits.

share|improve this answer
2  
Performance isn't something enforceable via a type check. It a promise of the implementer/library maintainer. –  dietbuddha Feb 10 '13 at 9:13
2  
I explicitly stated so in my answer? –  DeadMG Feb 10 '13 at 11:30
1  
My point was that as soon as you include anything other than type in the criteria you are no longer talking about Liskov as it is specific to type. While the "practice" of not subbing out differently performing objects may be good, Liskov itself has nothing to say about it. –  dietbuddha Feb 10 '13 at 21:18
4  
Liskov states that for the Derived, it should be usable anywhere a Base is. That may well not be true if the Base guarantees certain performances or characteristics. For example, if Derived blocks, there may be the potential for deadlocks. –  DeadMG Feb 11 '13 at 9:48

TL;DR: No

According to the "Behavioral Subtyping Using Invariants and Constraints" (the formalization of the principle) it is primarily concerned with "safety" properties of an objects type. Properties which govern substitutability only within the context of type information. An objects type is orthogonal to it's performance. Therefore a difference in performance is not a violation of the Liskov Substitution Principle.

share|improve this answer
1  
I had only a short look into that paper, but are you sure that timing constraints cannot be made formally provable? And even if Liskov did not mean that in words, including timing constraints could be seen as a good extension of the classical LSP which may be relevant to real-world programming. –  Doc Brown Sep 6 '13 at 6:40
    
@Doc Brown: whether timing is useful as a consideration to substituting an object or not is orthogonal to Liskov. To can add it as a sperate precept, but it cannot and will never be part of Liskov. It's like having a Boolean logic equation and saying !False can only be substituted by True if it's fast enough. Speed has nothing to do with math or logic. –  dietbuddha Mar 25 at 0:54

The performance of the software has nothing to do with the Liskov Substitution Principle.

The principle has to do with substitution of subtypes, and the behavioral impact of substituting that object in OOP terms only.

The input and output of getThing() remain the same for both cases, and both slow and fast likely put the objects into the same state.

share|improve this answer

What guarantees does the interface make? Since GetThing makes no guarantees then subtypes need not respect it.

If the interface was something like GetThingInLinearTime or if the base type is virtual and the default implementation is one complexity, then making that algorithmic complexity worse would violate LSP.

share|improve this answer

Does it matter what the Liskov Substitution Principle itself says specifically? If a subtype violates the expectations of the consumer of the supertype, that seems like a bad thing regardless of whether LSP is more restrictive.

So in my view, whether all reasonable expectations of the consumer of an abstraction are fulfilled by the subtype seems to be a good generalization of LSP.

However, in the example you have posted and with Java interfaces in general, it's not clear that the consumer of the Thing interface has any reasonable expectation of whether it should be fast or slow. If the interface's javadocs were to include language about what operations are promised to be fast, then there might be an argument for a problem on performance grounds. But the Java convention is certainly for various implementations to have different performance characteristics.

share|improve this answer
1  
as far as I can tell, example posted is not Java –  gnat Feb 10 '13 at 9:45

Uncle Bob answered a very similar question where he states that an LSP violation requires 3 parties:

The Type T, the Subtype S, and the program P that uses T but is given an instance of S.

I would venture a guess that this question has a similar structure as the one he replied to, in that it doesn't mention the P that's using the T and what behavior the P expects.

You can find his answer here. (You'll need to scroll down some and look for answer from user named Robert Martin)

share|improve this answer
    
how does this answer the question asked? –  gnat Sep 6 '13 at 6:39
    
@gnat Because the question, as asked, is incomplete. It takes 3 parties to determine an LSP violation. Of which, he only supplied 2 of the parties. –  TMc Sep 6 '13 at 18:32

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.