delegation vs. inheritance
in [OOP]
|
From: ulf on 15 Aug 2006 20:24 Dear Mr. Lahman, Your insulting of type systems ("down in the mud of 3GL type systems" etc.) requires me to throw in my own $.02 worth: > Responding to Kazakov... .... >>>> A, maybe more obvious, example is integers vs. positives. >>>> Each n>0 is an integer, yet positive is not an LSP-subtype of integer. >>>> [...] You cannot have both n>0 and existence of negative inverse. >>>> It is a hard fact. [...] > [...] > Don't forget that most of modern type theory would not exist if OO > techniques and OOPLs had not come along. [...] Yes, most likely. > Thus integers were quite nicely handled long before type theory. Yes. Among others, the mathematicians discovered: The set of positive integers is not closed under negation. This is not type theory. It's a logical consequence of the definitions of "positives" and "negation". It's a mathematical fact. > The OOPLs just raised the bar > from modeling simple hardware structures to modeling much more complex > concepts largely outside the realm of hardware. Yes. Because OOPLs were invented to express concepts outside the realm of hardware, they required a corresponding raise of the type system they had "inherited" from procedural languages. > [...] > > > 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 > > Actually, I see that the other way around. Type theory was very > specifically tailored to the 3GL abstraction model, [...] Yes. But LSP goes beyond type theory. That was the point of Liskov and Wing: That, while the subtyping notion from type theory is sufficient for handling the absence of execution errors, it does not suffice for handling consistency with the programmer's modelling intentions. For that you need, what they called a "behavioral notion of subtyping". Their observation applies equally in object-oriented modelling to what you call "class systems:" We need a behavioral notion of generalization/specialization. A simple example: Class A has a protected attribute x set in the constructor, and a message m1 computing a value F(x) based on x (and returing it or sending it to some other object). Hence a modeller of clients of A objects can expect that their x attribute can never change after construction. But then the A-client part of the model may be broken if the A-part of the model is extended by specializing A to a class B with an additional message m2 whose behavior includes changing the inherited x attribute, and if instances of B are created and brought into an A-client context. Liskov and Wing proposed a behavioral subtyping rule, which they proved to enforce the LSP. Let me try to translate it, AFAIKR, into OOM-talk to obtain a modelling rule. It should be sth like: In a generalization relationship between two classes, the subclass's modeled behavior on receiving an inherited message must be consistent with the superclass's behavior on that message - after the *same* history of message exchange - but also after histories containing additionally the exchange of the *new messages* introduced in the subclass (like m2 above). Ulf Schünemann
From: Dmitry A. Kazakov on 16 Aug 2006 04:59 On Tue, 15 Aug 2006 14:36:06 GMT, H. S. Lahman wrote: > Responding to Kazakov... > > 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. Again, it is a heavy conceptual disagreement between us. In my view, a properly functioning program is not equivalent to LSP satisfied. You are mixing domains and languages here. Basically, it is a fly and aerodynamics, once more. > Don't forget that most of modern type theory would not exist if OO > techniques and OOPLs had not come along. I am not so sure as you and Ulf are. More I think about types and category theories in mathematics, and the type theory as found in OOPL, more I get convinced that the underlying problematic is very close, if not same. >> 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? Stop, you cannot even spell "sorting" without identifying a set of squares to be sorted. You cannot sort anything individually, "individual" means that you already have sorted it out. > [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.] To be able to represent a set of all integers /= to be able to represent each integer in the set. This is why OO works (what some RDBMS guys don't get, BTW). We don't need to look into objects to be able to deal with them, to certain limits, of course. So we can model an infinite set of all integers as an object in some finite language. From which we can translate our model down to the finite language of our weak hardware. [ I think we are agree here in principle, otherwise you should have been sided with relational modeling hardliners... ] >>>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. [...] I agree here with Ulf. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de
From: H. S. Lahman on 16 Aug 2006 10:18 Responding to Ulf... > Your insulting of type systems ("down in the mud of 3GL type systems" > etc.) requires me to throw in my own $.02 worth: I wasn't insulting type systems. Kazakov and I have been around on this subject before. He essentially does not believe in OOA/D and feels that everything in OO software can be resolved with 3GL types. My position is that type are quite valuable, but only at the level of defining and implementing 3GLs appropriate for OOP. They are simply not relevant to OOA/D when designing an OO application; for OOA/D one only deals with class systems. > >><snip stuff we agree on> > >>Actually, I see that the other way around. Type theory was very >>specifically tailored to the 3GL abstraction model, [...] > > > Yes. But LSP goes beyond type theory. That was the point of Liskov and > Wing: That, while the subtyping notion from type theory is sufficient > for handling the absence of execution errors, it does not suffice for > handling consistency with the programmer's modelling intentions. For > that you need, what they called a "behavioral notion of subtyping". You will note that in the message you are responding to I made specific reference to the fact that OOA/D generalizes the notion of LSP to class systems. So we are still pretty much agreed. > > Their observation applies equally in object-oriented modelling to what > you call "class systems:" We need a behavioral notion of > generalization/specialization. A simple example: > > Class A has a protected attribute x set in the constructor, and a > message m1 computing a value F(x) based on x (and returing it or > sending it to some other object). > > Hence a modeller of clients of A objects can expect that their x > attribute can never change after construction. But then the A-client > part of the model may be broken if the A-part of the model is extended > by specializing A to a class B with an additional message m2 whose > behavior includes changing the inherited x attribute, and if instances > of B are created and brought into an A-client context. > > Liskov and Wing proposed a behavioral subtyping rule, which they proved > to enforce the LSP. Let me try to translate it, AFAIKR, into OOM-talk > to obtain a modelling rule. It should be sth like: > > In a generalization relationship between two classes, the subclass's > modeled behavior on receiving an inherited message must be consistent > with the superclass's behavior on that message > - after the *same* history of message exchange > - but also after histories containing additionally the exchange of the > *new messages* introduced in the subclass (like m2 above). Here we disagree somewhat. What you are describing here is implementation inheritance (i.e., the subclass overrides a defined property implementation that already exists in a superclass). This was one of those ideas in early OO development that seemed like a good idea at the time but in practice led to more problems than it cured. However, in modern practice one tries to avoid implementation inheritance for a variety of reasons, of which fragile maintainability is even more important that the potential for LSP problems. So in a well-formed OO application responsibilities are only implemented at the leaf subclass level, which creates an environment of pure substitution between subclass implementations of a superclass responsibility. My second problem here is with the implication that somehow there is s dependence between client messages that affects substitutability. In an OO context the responsibilities must be standalone (self-contained) so that clients may invoke them one a peer-to-peer basis as needed. They must also be intrinsic responsibilities that do not depend upon context. That is true regardless of whether the object is involved in a generalization or not. So the response the object in hand makes is independent of context (i.e., there is no message history that is relevant). [One can capture sequential behavior constraints in other ways, such as an object state machine's transitions. But that is orthogonal to the processing resulting when an object responds to a valid message.] LSP is only relevant to polymorphic dispatch among existing implementations of a responsibility. In OO polymorphic dispatch a client can send the same message to objects from different subclasses if the relevant responsibility is defined in a common superclass. The object in hand then responds with the implementation defined for its subclass. That only requires that the client be indifferent to the /implementation/ of the responsibility across the sibling subclasses. That is, the responsibility semantics at the superclass level must be defined in a manner that allows implementation substitution, which is where LSP enters the picture. That is a matter of abstraction and DbC contract between the client and the generalization within the context of the overall problem solution. ************* 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: H. S. Lahman on 16 Aug 2006 10:53 Responding to Kazakov... >>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. > > > Again, it is a heavy conceptual disagreement between us. In my view, a > properly functioning program is not equivalent to LSP satisfied. You are > mixing domains and languages here. Basically, it is a fly and aerodynamics, > once more. OBviously a functioning program is going to depend on a lot more than just LSP being being satisfied. But LSP compliance is still a good way to ensure proper functioning. I don't like the fly and aerodynamics analogy. LSP in an OO context is about defining the /intrinsic/ properties of a fly. To that end one needs to abstract -- at most -- a very restricted view of aerodynamics that is needed to describe how the fly itself works in the problem context. One is not interested in how aerodynamics applies to airplanes or Frisbees. >>>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? > > > Stop, you cannot even spell "sorting" without identifying a set of squares > to be sorted. You cannot sort anything individually, "individual" means > that you already have sorted it out. Your first sentence is exactly my point. To do anything useful with squares (i.e., to manipulate or process them in some way) one needs to deal with them on an individual basis. To do that they must be identifiable as individual members of the set. >>[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.] > > > To be able to represent a set of all integers /= to be able to represent > each integer in the set. This is why OO works (what some RDBMS guys don't > get, BTW). We don't need to look into objects to be able to deal with them, > to certain limits, of course. So we can model an infinite set of all > integers as an object in some finite language. From which we can translate > our model down to the finite language of our weak hardware. > > [ I think we are agree here in principle, otherwise you should have been > sided with relational modeling hardliners... ] Yes and no. My issue was around individual members of the set. Sure, one can deal with larger integers in a variety of ways, with or without objects. But when you do so you are artificially subdividing the mathematician's notion of 'integer' and modifying it, which was my point. Thus when the 3GL defines "int" as a fundamental type, it ain't your mathematician's 'integer' any more that your Silver Ghost object is your rare car dealer's notion of 'Silver Ghost'. ************* 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: ulf on 16 Aug 2006 21:16
H. S. Lahman wrote: > Responding to Ulf... > > > Your insulting of type systems ("down in the mud of 3GL type systems" > > etc.) requires me to throw in my own $.02 worth: > > I wasn't insulting type systems. ... OK. > My position is that type are quite valuable, but only at the level of > defining and implementing 3GLs appropriate for OOP. They are simply not > relevant to OOA/D when designing an OO application; for OOA/D one only > deals with class systems. Here we disagree. I, maybe unconventionally, distinguish between the notion of type system 1 - as a system of rules assigning static types to type correct program terms, and 2 - as a system of types related by type constructors and subtype relationships. IMHO, a class system is - on the right level of abstraction - a type system in the second sense. > > Liskov and Wing proposed a behavioral subtyping rule, which they proved > > to enforce the LSP. Let me try to translate it, AFAIKR, into OOM-talk > > to obtain a modelling rule. ... > > Here we disagree somewhat. What you are describing here is > implementation inheritance (i.e., the subclass overrides a defined > property implementation that already exists in a superclass). I intended not to describe implementation inheritance but specification inheritance. The problem is not inherited behavior implementations are overridden. The problem is: What the behavior implementation finally is in the concrete instance is not compatible to the assumptions under which interactions involving superclass instances were modeled. For the problem to arise it does no matter whether these assumptions were derived from actual behavior implementations in the superclass or from specifications of behavior in the superclass or intuitively from the superclass's name and informally described purpose. > This was > one of those ideas in early OO development that seemed like a good idea > at the time but in practice led to more problems than it cured. Agreed. > My second problem here is with the implication that somehow there is s > dependence between client messages that affects substitutability. Huh? The existence of such dependencies is a fact: Since messages received in the past can influence the state an object is in now, they can affect the object's externally visible behavior now, and thus can affect its substitutability. > In an > OO context the responsibilities must be standalone (self-contained) so > that clients may invoke them one a peer-to-peer basis as needed. They > must also be intrinsic responsibilities that do not depend upon context. I don't understand. Do you mean diachronic or synchronic context? > ... > LSP is only relevant to polymorphic dispatch among existing > implementations of a responsibility. I think you misunderstand LSP - see "implementation inheritance" above. > In OO polymorphic dispatch, a client ... Agreed with this definition. > That only requires that the client be indifferent to the > /implementation/ of the responsibility across the sibling subclasses. Yes. That = "OO polymorphic dispatch" requires only this to function. > That is, the responsibility semantics at the superclass level must be > defined in a manner that allows implementation substitution, which is > where LSP enters the picture. That is a matter of abstraction and DbC > contract between the client and the generalization within the context of > the overall problem solution. Yes. The client cannot be indifferent to externally visible effects of the behavior - This is what the notion of contract is there for. The surprising thing to me in Liskov and Wing's TOPLAS paper "A behavioral notion of subtyping" was that invarants and pre/postconditions are not always capable of expressing behavior a client may want to be indifferent to. For example one may want to capture in the contract of a counter-like class that the counter value can never decrease, but only increase. This is not an invariant (a property over each possible state), but what Liskov and Wing call a "history property" (a property over two (consecutive) states). - cf. my reply to Mr. Perryman. Ulf Schünemann |