1

Wiki says:

Substitutability is a principle in object-oriented programming stating that, in a computer program, if S is a subtype of T, then objects of type T may be replaced with objects of type S (i.e. an object of type T may be substituted with any object of a subtype S) without altering any of the desirable properties of T (correctness, task performed, etc.).

My understanding from this,

If T is an abstraction that provides encapsulation to protect invariants of state maintained by instances of T, then S is an abstraction that MUST at-least provide encapsulation to protect same invariants of those inherited states maintained by instances of S.

Here abstraction can not not only be a class but also a function. For example: function written in prototypical paradigm(ES5 JavaScript)

A class(T or S) knows, the contracts their instances should obey.

LSP is about S ensuring encapsulation to protect invariant of state, that gets inherited from T. My understanding is, correctness is about protecting invariants to maintain correctness of state.

Is that the right understanding?

Robert Harvey
  • 200,592
user1787812
  • 769

3 Answers3

10

No, I don't think so.

LSP says that S can substitute for T. What that means in practice is that S fulfills the same contractual obligations that T does. The writer of S can expose internal state (thereby breaking encapsulation) without violating the original API contract.

State is an implementation detail, not a behavior.

Robert Harvey
  • 200,592
3

Not completely. If some base class provides an immutability guarantee for its state, then its subtypes should also provide that guarantee. If some base class guarantees some invariant relation for its state, then its subtypes should also make that guarantee. But there's also a lot more "desirable properties" of classes (and functions) than how their state behaves.

Another good way to look at it is described in Liskov's original paper, which this question summarizes: subtypes should not strengthen preconditions or weaken postconditions.

Telastyn
  • 110,259
-4

Yes, it is all about preserving invariants, as well as preconditions and postconditions. However, Liskov substitution is not a principle, simply something that you must do in order to perform software engineering using contracts.

When encapsulation is complete, a derived class cannot change the state invariants of the base class, even if the author desires to perform such a change.

The word "principle" was added about the same time widespread misunderstandings of Liskov's work began to emerge. If you read her original book with Guttag, Abstraction and Specification in Program Development (using CLU), or her later works about type substitution, you will find it is all about formal and informal contract specifications. For some reason, Liskov's ideas were eventually interpreted as being about the implementation of method signatures in languages such as Java that support interfaces. Of course such languages have no contracts so you can have many interpretations about what the contract should be.

Frank Hileman
  • 3,952