3 ms·

perhaps more than the LSP, this should be a textbook illustration of why representations of mutable objects in a program should not be named after entities in t

perhaps more than the LSP, this should be a textbook illustration of why representations of mutable objects in a program should not be named after entities in the domain whose essential identity is associated with one or more attributes that are mutable in the representation. Yes, in the example I gave, I agree. Certainly objects such as Rectangles and Squares should be modeled as immutable value objects. Immutability solves the problem completely. The example would perhaps be better if instead of Rectangles and Squares it talked about Windows and FixedAspectWindows.

dragonwriter 10y ago
> The example would perhaps be better if instead of Rectangles and Squares it talked about Windows and FixedAspectWindows. But, here, I think it should be quite clear that the solution is to make clear that independence of the dimensions on the two axes is not a guarantee provided by the Window interface or class. Interdependence of a particular form is guaranteed by FixedAspectWindow, and there might be a similar subtype of FlexibleAspectWindow that guarantees independence, but Window itself should not make any guarantee (and should, if necessary for clarity, expressly disclaim such a guarantee.) But one thing I think that it is worth highlighting is that the fact that some guarantees of a type are expressable and enforceable through code does not ensure that all are, and the LSP most critically applies to those that are not (since those that are expressed and guaranteed through code won't ever be a problem), but to those that are communicated through other mechanisms, including those communicated implicitly through naming.
- dllthomas 10y ago
  > including those communicated implicitly through naming As an aside, this is an aspect of what I like about choice of names like "Functor" and "Monoid". There is very little room for ambiguity. Further aside... In Haskell, there's still "do we include operational equivalence?" and "are we considering equivalence only up to bottom?". But at least the guarantees around the semantics for non-bottom values are reliably uncontroversial.

dragonwriter 10y ago

> The example would perhaps be better if instead of Rectangles and Squares it talked about Windows and FixedAspectWindows. But, here, I think it should be quite clear that the solution is to make clear that independence of the dimensions on the two axes is not a guarantee provided by the Window interface or class. Interdependence of a particular form is guaranteed by FixedAspectWindow, and there might be a similar subtype of FlexibleAspectWindow that guarantees independence, but Window itself should not make any guarantee (and should, if necessary for clarity, expressly disclaim such a guarantee.) But one thing I think that it is worth highlighting is that the fact that some guarantees of a type are expressable and enforceable through code does not ensure that all are, and the LSP most critically applies to those that are not (since those that are expressed and guaranteed through code won't ever be a problem), but to those that are communicated through other mechanisms, including those communicated implicitly through naming.

dllthomas 10y ago
> including those communicated implicitly through naming As an aside, this is an aspect of what I like about choice of names like "Functor" and "Monoid". There is very little room for ambiguity. Further aside... In Haskell, there's still "do we include operational equivalence?" and "are we considering equivalence only up to bottom?". But at least the guarantees around the semantics for non-bottom values are reliably uncontroversial.