Re: delegation vs. inheritance

Responding to Kazakov...

I think a square having four sides of equal length is <part of> the formal definition of a square. So with respect to defining side length using four sideLengthN (N = 1..4) attributes is a valid abstraction (the equality is enforced in initializing the attributes). Similarly, using one sideLength is a valid abstraction.


Yes, any true proposition about square remains true independently on
whether we are aware of other propositions.


The difference lies in whether LSP is an issue; if one also needs a definition that is consistent with Rectangle, then only the first abstraction of the geometric properties works.


The point is that, surely, you can take any set of propositions about
squares, name them abstractions, and find some of them being compatible
with rectangles. BUT, there are propositions which actually make squares
what they are, like width=height is. One could find small sets of those,
from which one could infer all others. This is how mathematicians define
their objects. Let name them sufficient sets. Now, each such sufficient set
will not be a subset of the set of propositions about rectangles.

OK, but in an OO context one has a variety of ways to abstract. One can enforce the rule of four sides with four length attributes. Similarly, one can enforce the rule that width=height in the constructor. To me that versatility /enables/ one to deal with LSP in generalizations.

In other words, you can model squares as IS-A rectangles, but they won't be
much square...

Why not? The generalization is that both have four sides and the opposing sides must have equal length. Any figure satisfying those propositions can be inferred to be member of the rectangle set. The specialization is that opposing and adjacent sides also have equal length. Any figure satisfying that proposition as well can be inferred to be a member of the square subset. So a Square is-a square in the mathematical sense. But it is-a rectangle in the mathematical sense as well.

Nonetheless I think LSP is quite useful in an OO context because one tailors object abstractions to the problem in hand. That allows one to use tricks like abstraction and a flexible view of logical indivisibility to make many LSP issues in the problem space irrelevant to the solution context. IOW, one only has to resolve the LSP issues that are relevant to the problem in hand.

True, but to me that means a defeat of LSP as a principle. It was
introduced solely to ensure substitutability. When you say OK, we have to
check for substitutability in each given case (context), then you merely
return back to the beginning.

I see the issue differently. LSP requires that one define what substitutability means in the current problem context and then construct the classes, interfaces, and client contracts around that definition.


I agree with that, but I see no contradiction.

My issue here is with the notion that one has to check for substitutability as some sort of special A&D activity. I argue that one simply constructs the relevant entities properly in the first place. So when one defines a collaboration that collaboration must be consistent with the definitions of the rest of the design elements. IOW, dealing with LSP is part of the basic A&D process.

The real problem here is that current 3GLs do not document what such definitions are. If those definitions are not documented elsewhere, then future maintainers do have to check every context when making a change. If those changes are documented, then the maintainer only needs to check client contexts if the change modifies the original definition of substitutability


Again agree. That were a pragmatic solution I liked to have much. But in my
eyes it still kills LSP subtyping idea. You say, look, let at the
declaration point subtype be anything you wish. Most of the questions about
substitutability are postponed until instantiation, when the context will
be known. As long as that happens no later compile time, I don't worry.

Hmmm. I see documenting the design decisions as completely orthogonal to LSP. If the original design was constructed consistent with LSP, then that consistency is a fact regardless of whether it is documented. That a future maintainer can't easily figure out what the original substitutability definitions were is not an LSP problem; it is a design documentation problem.


*************
There is nothing wrong with me that could
not be cured by a capful of Drano.

H. S. Lahman
hsl@xxxxxxxxxxxxxxxxx
Pathfinder Solutions
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
"Model-Based Translation: The Next Step in Agile Development". Email
info@xxxxxxxxxxxxxxxxx for your copy.
Pathfinder is hiring: http://www.pathfindermda.com/about_us/careers_pos3.php.
(888)OOA-PATH



.

Relevant Pages

  • Re: Why is OO Popular?
    ... Something forgotten by the LSP. ... There are many kinds of substitutability. ... "variable substitutability" is not atomic. ... >A rectangle is a generalization of a square and not a specialization. ...
    (comp.object)
  • Re: delegation vs. inheritance
    ... but then I would wonder if squares aren't either. ... to the solution context. ... one only has to resolve the LSP issues ... check for substitutability in each given case, ...
    (comp.object)
  • Re: delegation vs. inheritance
    ... responsibility is defined in one and only one place: ... superclass context to a more specific, refined model in the context of ... Thus in an OO context LSP comes down to ensuring that the superclass responsibility semantics is defined with sufficient detail to be useful to clients while also ensuring sufficient generality so that it is consistent with all the subclass implementations. ... dependence between client messages that affects substitutability. ...
    (comp.object)
  • Re: delegation vs. inheritance
    ... the debate centered around deriving Rectangle behaviors from Square behaviors. ... The real problem was that Square was defined with a sideLength knowledge attribute while Rectangle was defined with majorSideLength and minorSideLength -- apples & oranges. ... So if one defined sideLengthN for Square, then Rectangle could be a subclass without any LSP inconsistency in the knowledge attributes. ...
    (comp.object)
  • Re: Why is OO Popular?
    ... There are many kinds of substitutability. ... >inheritance in subtyping and specialization by constraint then we can ... rectangle class does not know that you will derive square from it. ... >But subtyping is not about code reuse. ...
    (comp.object)
Loading