Re: delegation vs. inheritance

Responding to Kazakov...

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.


Where is a guaranty that the result will be a square? I doubt there could
be any. The process of abstraction was long ago made by ancient Greeks.
Either the new abstraction is equivalent to that geometric set of squares
or not. My point is simple: any abstraction that does not violate LSP
*cannot* be an abstraction of squares.

Sure, those attributes are insufficient. The sides have to form a closed shape and the interior angles have to be 90 degrees. But those are just additional constraints in the definition of a square that need to be abstracted.

Describe all the relevant propositions of a square with geometric precision and each of them can be abstracted. The Square abstraction will then be a square in the same sense as the geometric shape.

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.


You are talking about individual objects here. But LSP deals with types and
so with sets of objects. A, maybe more obvious, example is integers vs.
positives. Each n>0 is an integer, yet positive is not an LSP-subtype of
integer. The proposition forall x in Integer exists -x in Integer, such
that x + -x = 0, does not hold for positives. You cannot have both n>0 and
existence of negative inverse. It is a hard fact. When you drop the first,
the result won't be positive, when you do the second the result won't be
integer (maybe a group, but not integers).

Yes, I am talking about objects here. And you are down in the mud of 3GL type systems again. B-) You've really got to get out of there, smell the roses, and deal with OOA/D class systems. We're talking about object abstractions, not OOPL implementations in a hardware environment.

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.


OK, but the goal of design is to communicate to other people including
yourself later on. A design nobody can understand is worthless. One can
violate any principle except this one.

I agree. Which is one reason I can't buy the commonly held notion that one can write 3GL code that is self-documenting without the need for comments or other external documentation. 3GLs simply do not allow one to capture Why the designer did the design a particular way.


*************
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: Cantorian pseudomathematics
    ... > is the diagonal of the square - another abstraction. ... > measure a physical representation of the diagonal of a square. ... With that we loose ... >> However, because of formalism, we can at least all agree on one thing: ...
    (sci.math)
  • Re: Reach and picking up objects
    ... One thing you people on the wrong side of the fence keep forgetting is ... Likewise the 5' square is an abstraction, ... could literally have something in the adjacent square at your feet. ...
    (rec.games.frp.dnd)
  • Re: Enigma 1452 - Crossed lines
    ... calculated the number of rectangles which could be seen in this new ... large square grid. ... Suppose the new pieces had dimensions a x, ... Hence we derive an infinite sequence of pairs. ...
    (rec.puzzles)
  • Re: Enigma 1452 - Crossed lines
    ... calculated the number of rectangles which could be seen in this new ... large square grid. ... Suppose the new pieces had dimensions a x, ... Hence we derive an infinite sequence of pairs. ...
    (rec.puzzles)
  • Re: OO Concept: Liskov Substitution Principle
    ... The article said Rectangle class should not be a superclass of Square ... so how you would design the Rectangle & Square class? ... Squares are not Rectangles either. ... There is nothing wrong with having a Square class with both a setHeightand a setWidthmethod. ...
    (comp.lang.java.programmer)