delegation vs. inheritance
in [OOP]
|
From: H. S. Lahman on 11 Aug 2006 10:05 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(a)pathfindermda.com Pathfinder Solutions http://www.pathfindermda.com blog: http://pathfinderpeople.blogs.com/hslahman "Model-Based Translation: The Next Step in Agile Development". Email info(a)pathfindermda.com for your copy. Pathfinder is hiring: http://www.pathfindermda.com/about_us/careers_pos3.php. (888)OOA-PATH
From: Dmitry A. Kazakov on 14 Aug 2006 03:42 On Fri, 11 Aug 2006 14:05:26 GMT, H. S. Lahman wrote: > 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. >> 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). > 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. Yes >>>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. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de
From: H. S. Lahman on 14 Aug 2006 10:41 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(a)pathfindermda.com Pathfinder Solutions http://www.pathfindermda.com blog: http://pathfinderpeople.blogs.com/hslahman "Model-Based Translation: The Next Step in Agile Development". Email info(a)pathfindermda.com for your copy. Pathfinder is hiring: http://www.pathfindermda.com/about_us/careers_pos3.php. (888)OOA-PATH
From: Dmitry A. Kazakov on 15 Aug 2006 09:05 On Mon, 14 Aug 2006 14:41:28 GMT, H. S. Lahman wrote: > 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. Constraints which eventually break LSP... >> 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-) It is much worse, than that. It is the reality. (:-)) > You've really got to get out of there, > smell the roses, and deal with OOA/D class systems. You know that I don't believe in OO of individual objects. I don't even count it for abstraction in a higher sense of that word. What would be out of geometry if one considered each square individually?.. > We're talking about > object abstractions, not OOPL implementations in a hardware environment. OK, that is a lower kind of abstraction which is specific to OO. But LSP has a wider context. When you talk about object abstractions you have no LSP, just substitutability. LSP is an abstraction of substitutability, an idea of. It is cognition of substitutability issues. If it happens to you that you [unconsciously] get a working program, nice, but it is not LSP. A fly knows nothing about aerodynamics, yet it flies. So it could argue that aerodynamics is not an issue. Maybe it would be even right... (:-)) -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de
From: H. S. Lahman on 15 Aug 2006 10:36
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. > > > Constraints which eventually break LSP... Not if they are abstracted properly for the problem in hand. I agree that OO abstraction is limited and, therefore, one cannot exactly match the underlying entity. That is pretty much in the nature of abstraction. But one can match reality closely enough in particular problem contexts to satisfy LSP. Better yet, one can ensure robustness in the OO application by /requiring/ LSP compliance for the particular problem in hand. IOW, one does not ignore LSP when a particular set of property abstractions don't support compliance properly for the problem in hand; one finds a different suite of property abstractions that do support it. >>>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-) > > > It is much worse, than that. It is the reality. (:-)) Don't forget that most of modern type theory would not exist if OO techniques and OOPLs had not come along. (More precisely, wouldn't have been introduced when it was; mathematicians are a curious lot and somebody would have gotten there eventually.) Thus integers were quite nicely handled long before type theory. The OOPLs just raised the bar from modeling simple hardware structures to modeling much more complex concepts largely outside the realm of hardware. >>You've really got to get out of there, >>smell the roses, and deal with OOA/D class systems. > > > You know that I don't believe in OO of individual objects. I don't even > count it for abstraction in a higher sense of that word. What would be out > of geometry if one considered each square individually?.. I have a hundred squares of various sizes. No matter how I represent them, is not each one individually identifiable? More important, is it not useful for processing like sorting to be able to identify and consider them individually? [Note, BTW, that there is no 3GL language implementation or computer in the world that can represent any possible integer as a single number. So even those "pure" hardware and 3GL type systems have the same sorts of problems with abstract representation that you are attributing to OO objects.] >>We're talking about >>object abstractions, not OOPL implementations in a hardware environment. > > > OK, that is a lower kind of abstraction which is specific to OO. But LSP > has a wider context. When you talk about object abstractions you have no > LSP, just substitutability. LSP is an abstraction of substitutability, an > idea of. It is cognition of substitutability issues. If it happens to you > that you [unconsciously] get a working program, nice, but it is not LSP. A > fly knows nothing about aerodynamics, yet it flies. So it could argue that > aerodynamics is not an issue. Maybe it would be even right... (:-)) > Actually, I see that the other way around. Type theory was very specifically tailored to the 3GL abstraction model, just like Codd's RDM was very specifically tailored to hard disk storage. Both are abstracted and formalized mathematically, but the underlying structure still has very specific roots. So whether type theory or the RDM can be applied outside the computing space is problematic. However, by applying LSP at the OOA/D level where there are no types (other than knowledge attribute ADTs) one is actually generalizing type theory the same way that one generalizes the RDM to normalize Class Models for behavior as well as data. -- ************* There is nothing wrong with me that could not be cured by a capful of Drano. H. S. Lahman hsl(a)pathfindermda.com Pathfinder Solutions http://www.pathfindermda.com blog: http://pathfinderpeople.blogs.com/hslahman "Model-Based Translation: The Next Step in Agile Development". Email info(a)pathfindermda.com for your copy. Pathfinder is hiring: http://www.pathfindermda.com/about_us/careers_pos3.php. (888)OOA-PATH |