18

LSP states that classes should be substitutable for their base classes, meaning that derived and base classes should be semantically equivalent.

But does LSP also apply to classes implementing an interface? In other words, if an interface method implemented by a class is semantically different from what user expects it to be, would this be considered as a violation of LSP?

gnat
  • 21,442
  • 29
  • 112
  • 288
user1483278
  • 1,121
  • 1
  • 10
  • 14
  • 7
    Yes. Exactly same reasons and results as violating LSP if it's an interface, an abstract class, a full class, doesn't matter. LSP is about setting and meeting expectations to allow consumers to treat your types in a general way. – Jimmy Hoffa Oct 22 '12 at 18:55
  • 5
    By and large (I know the differences, but I'm generalizing here), interfaces are somewhat analogous to pure abstract classes (C++ term) and therefore Liskov should apply to interfaces and the classes which implement them. – Jesse C. Slicer Oct 22 '12 at 18:56
  • 3
    NB the formulation of the LSP I'm familiar with speaks of subtypes rather than derived and base classes. With good reason, I assume, because none of the reasons is specific to inheritance and applies just as well for any other kind of subtyping. –  Oct 22 '12 at 19:09

1 Answers1

17

if an interface method implemented by a class is semantically different from what user expects it to be, would this be considered as a violation of LSP?

If the implementation is semantically different from the behavior documented through the invariants of the interface and its methods' pre- and post-conditions, then the answer is "yes", it would be a violation of the LSP. The principle establishes the rules for the abstraction and its implementations, without requiring the abstraction side to be present in the form of a class.

However, if we talk about what users expect, the answer would be "not necessarily": the users are entitled to having wrong expectations.

Sergey Kalinichenko
  • 17,393
  • 4
  • 57
  • 73
  • "If the implementation is semantically different from the behavior documented through the invariants of the interface" Could you elaborate on what you mean by "invariants of the interface"? – user1483278 Oct 22 '12 at 21:35
  • 3
    @user1483278 Here is an article about [type invariants](http://en.wikipedia.org/wiki/Class_invariant). The article calls them "Class invariants", but the description applies to interfaces as well. Invariants are conditions that are established at construction, and maintained throughout the lifetime of an instance. For example, if an interface has a property `Name` that cannot be set to `null`, then `obj.Name != null` is said to be an *invariant* of that interface. – Sergey Kalinichenko Oct 22 '12 at 21:57
  • 1
    Typically when invariants are discussed, it is possible to write a piece of code to verify that the invariant is upheld over the entire lifetime of the object. However, it is typically more straightforward to verbally describe the invariant in plain English. – rwong Oct 23 '12 at 03:21