delegation vs. inheritance
in [OOP]
|
From: H. S. Lahman on 5 Sep 2006 11:34 Responding to Kazakov... >>>>As I illustrated in the Car example a couple of messages ago, A Drive >>>>Train is not a Car by any stretch of the imagination. They are quite >>>>different things and they share no properties. There is no relation >>>>between their types; there is only a logical association between objects. >>> >>> >>>You didn't say *what* you wanted to delegate and how this managed to stay >>>not shared. >> >>In the original examples, >> >><examples> >>In some problem context I may have a notion of Car. That Car will have >>a drive train in the problem space. But if my problem context doesn't >>need to know anything special about the drive train (e.g., the >>application in an inventory control program), I can abstract the notion >>of a drive train as simply properties of a [Car] abstraction >>(horsepower, fuel consumption, etc.) without any delegation of >>generalization. >> >>OTOH, if my problem space is an auto assembly plant, the drive Train >>exists independently of the Car until it is incorporated in the >>assembly. So I need to model the Drive Train as an object independent >>of Car that becomes a component of a Car. But the Drive Train is not a >>Car in that context by any stretch of the imagination so no >>generalization relations exists between them. All one has is a simple >>conditional association between peer objects. >></examples> >> >>The first paragraph represents Car without delegation while Drive Train >>is clearly delegated from Car in the second paragraph. When that >>delegation is abstracted all the properties (horsepower, fuel >>consumption, etc.) that are related to a drive train are removed from >>Car and allocated to the Drive Train object. There is no longer any >>shared semantics; Car and Drive Train only have an association to >>determine which members of their respective sets may collaborate. > > > This still does not answer the question: what does Car delegate to Drive > Train? All the properties that are logically related to a Drive Train. Without delegation the Car has properties like 'horsepower' because it has a drive train at that level of abstraction. After the delegation only Drive Train has such properties. > > And "semantics" is not something you could "store", "allocate", "keep" etc. > Semantics is a relation between signs and what they represent. If a car > represents a drive train, this does not necessary mean that it physically > is a drive train. Your representative in the Congress is not you, though > you *delegated* to him some of your constitutional rights. When you > exercise your rights through him, it does not mean that he lives in your > home and wears your socks... The problem here is fundamental OOA/D abstraction (or abstraction in general, for that matter!). A 'car' is a physical entity in the problem space that one needs to abstract. How one abstracts it depends on what is important about it to the problem in hand. A car doesn't represent a drive train in the problem space; it physically has one _if all one needs to explicitly identify is a 'car'_. If I represent the Car as an object without delegation, then I must represent the relevant properties it has in the problem space, which includes those of its drive train. However, if I view the problem space at a lower level of abstraction where a drive train is an independent, identifiable, standalone, physical component of a car, then I have to abstract the the Drive Train as an independent, identifiable, standalone object. At that point there are no shared properties between them. Nor, as a client, do you "exercise your rights through him". In the OO paradigm, if you need to collaborate with a Drive Train, you navigate relationships directly to it and collaborate on a peer-to-peer basis. The fact that one of those relationships happens to be between Car and Drive Train is irrelevant because navigating relationship paths is orthogonal to the class semantics of the object along that path. In fact, to "exercise your rights through him" you would have to include the Drive Train interface in the Car interface. That would create an unnecessary dependency of the Car abstraction on the Drive Train abstraction. So when the Drive Train interface changed, then the Car interface would also have to change. That's a major no-no in OO practice. <aside> To illustrate the point, consider the model: [Mechanic] | * | | R1 | | is associated with | 1 [Car] | 1 | component of | | R2 | | 1 [DriveTrain] In some method of [Mechanic] that needs to deal with a DriveTrain, the abstract action language (AAL) code use for UML OOA/D would look something like: ref = this -> R1 -> R2 // navigate relationships GENERATE M1 ref ... // issue collaboration message where 'M1' is a message identifier and '...' is whatever data one wants to send with the message. The important thing to note here relative to this thread is the [Mechanic] method needs to know absolutely nothing about the semantics of either [Car] or [DriveTrain] -- not even their class names! All it relies on is that whoever is on the end of the relationship path will be able to accept an 'M1' message (which is the developer's responsibility to ensure). The point here is that in OOA/D peer-to-peer collaboration is institutionalized in terms of relationship navigation so that collaboration is a personal matter between only the client and the service. In fact, the relationship navigation is so abstract that full code generators from UML models typically treat relationship implementations as class-cutting aspects. IOW, most of the constraints and conventions of the 3GL type systems are irrelevant. </aside> > > >>>>>>IOW, objects collaborate on a peer-to-peer basis. >>>>> >>>>>OK, that's the same disagreement between us. There is no peers at the >>>>>abstraction level of types. You won't get me back down to the ad-hockery of >>>>>individual objects... (:-)) >>>> >>>>Dmitry, I got to ask it: what are you doing on an OO forum if you refuse >>>>to accept the most fundamental tenets of OOA/D? >>> >>>As I said, we have different views on what OO is. This includes A/D. >> >>An interesting Freudian Typo (A/D vs. OOA/D). B-) > >
From: Dmitry A. Kazakov on 5 Sep 2006 13:03 On Tue, 05 Sep 2006 15:34:10 GMT, H. S. Lahman wrote: > Responding to Kazakov... > >> This still does not answer the question: what does Car delegate to Drive >> Train? > > All the properties that are logically related to a Drive Train. Without > delegation the Car has properties like 'horsepower' because it has a > drive train at that level of abstraction. After the delegation only > Drive Train has such properties. = car has delegated implementation of these properties to a drive train. Such properties are still exposed in the car's interface. They are of the car, while the act of delegation is merely an implementation detail. >> And "semantics" is not something you could "store", "allocate", "keep" etc. >> Semantics is a relation between signs and what they represent. If a car >> represents a drive train, this does not necessary mean that it physically >> is a drive train. Your representative in the Congress is not you, though >> you *delegated* to him some of your constitutional rights. When you >> exercise your rights through him, it does not mean that he lives in your >> home and wears your socks... > > The problem here is fundamental OOA/D abstraction (or abstraction in > general, for that matter!). A 'car' is a physical entity in the problem > space that one needs to abstract. How one abstracts it depends on what > is important about it to the problem in hand. > > A car doesn't represent a drive train in the problem space; it > physically has one _if all one needs to explicitly identify is a 'car'_. > If I represent the Car as an object without delegation, then I must > represent the relevant properties it has in the problem space, which > includes those of its drive train. Properties of a car are independent on whether computerized models of those are delegated or not. A car from the problem space delegates nothing. It is absurd to think otherwise, provided, we aren't going to fall into OO religion, claiming that physical world is OO. [...] > In fact, to "exercise your rights through him" you would have to include > the Drive Train interface in the Car interface. Sure. Otherwise, delegation would be an implementation detail. Anything not exposed in the interfaces just does not exist. Your examples illustrate low-level implementation details. [example skipped] >>>>>>>IOW, objects collaborate on a peer-to-peer basis. >>>>>> >>>>>>OK, that's the same disagreement between us. There is no peers at the >>>>>>abstraction level of types. You won't get me back down to the ad-hockery of >>>>>>individual objects... (:-)) >>>>> >>>>>Dmitry, I got to ask it: what are you doing on an OO forum if you refuse >>>>>to accept the most fundamental tenets of OOA/D? >>>> >>>>As I said, we have different views on what OO is. This includes A/D. >>> >>>An interesting Freudian Typo (A/D vs. OOA/D). B-) >> >> It was not a typo, I intentionally used it without OO. Not all A/D is OO, >> and OO is not exclusively about A/D. > > Ok, then my original question still stands: if your A/D is not OOA/D, > then what are you doing on a forum like comp.object? Are you sure that this forum follows your orthodoxy? (:-)) Even if it did, I enjoy opinions different from mine. >>>IMO, whatever you >>>are doing for A/D clearly isn't OOA/D. That's because you can't do >>>OOA/D if you restrict your thinking to types. One can make a strong >>>case for the assertion that the evolution of OOA/D since Smalltalk was >>>driven in no small part by the need to avoid the foot-shooting that >>>became apparent when people actually started using the OOPL type systems. >>> >>>Types represent a major compromise with hardware models (e.g., explicit >>>support of procedural message passing). As a result those compromises >>>make it very easy to overlay procedural design techniques onto the >>>OOPLs. They also have nasty side effects like physical coupling. >>>Proper OOA/D is required to ensure that those compromises don't >>>introduce problems like hierarchical dependencies and physical coupling. >> >> Types don't restrict anything. They just cannot do that, because type is an >> abstraction. [ Proof: make each object singleton. q.e.d. ] > > They don't restrict anything?????? You have to be pulling my chain here. > > Tell that to all the OOP programmers who spend a substantial part of > their time doing dependency management refactoring _after the > application is demonstrated to work correctly_. All they are doing is > overcoming the shortcomings of the OOPLs in order to make the > application more maintainable. One doesn't have that problem with > executable OOA/D models; when they execute correctly, they are done. They do it for the sake of re-use. Models based on individual objects have no validity beyond their direct application purpose. Cars are designed to go into production. People want to learn. Refactoring (largely based on the type system) is a cognition process of software construction. It is programming as a scientific activity. >> Since you have returned to the core of our disagreement. I repeat the point >> I made in our previous discussions. "Peer-to-peer collaboration" is the >> *lowest* possible abstraction level. You could claim that logging is a peer >> to peer collaboration between an axe and a tree, but that would impress >> nobody. The problem at hand is to deal with forests and cubic kilometers of >> wood. It is a way different level. > > But in an OO application the Axe does collaborate with an individual > Tree directly rather than through a Forest. But the real problem here > is that you are mixing levels of abstraction; forests and logging are at > a quite different level of abstraction than an individual logger and an > individual tree. I didn't mix them, I illustrated you a real difference in abstraction levels. The difference is between individual and common. An individual car in car construction is as uninteresting as an individual tree for logging. Their individualities are irrelevant as long as they do not clash with the commonalities. Type is a tool to deal with such things. If UML will ever evolve in something decent, it will become types as well. These types will have diagrams as values and operations defined on diagrams. You can't get rid of types. -- Regards, Dmitry A. Kazakov http://www.dmit
From: ulf on 5 Sep 2006 18:54 Stefan Ram wrote: > ulf(a)cs.mun.ca writes: > >... the original OO paradigm(s) of > >Jacobson/Meyer/Booch/Rumbaugh in the 1990s, where client-server > >relationships played a major role. > > If you consider 1990s work "original", how do you label > the 1977 work of Hewitt ... or the 1967 work of Kay ... My appologies. Originally I intended to mention also the more early development of the OO idea around OO PLs, including Simula, ST, Self, Loops... But since my point was to contrast Mr Lahman's depiction of what "the OO paradigm", and Mr Lahman has an issue with "3GLs", I then decided to skip them and focus on the OO methods of the named OO "gurus". Ulf Schünemann
From: S Perryman on 6 Sep 2006 05:01 "Dmitry A. Kazakov" <mailbox(a)dmitry-kazakov.de> wrote in message news:10kl5qhtitkv5.56sgxn4719cu$.dlg(a)40tude.net... > On Tue, 05 Sep 2006 15:34:10 GMT, H. S. Lahman wrote: >> Responding to Kazakov... >>>>Types represent a major compromise with hardware models (e.g., explicit >>>>support of procedural message passing). As a result those compromises >>>>make it very easy to overlay procedural design techniques onto the >>>>OOPLs. They also have nasty side effects like physical coupling. >>>>Proper OOA/D is required to ensure that those compromises don't >>>>introduce problems like hierarchical dependencies and physical coupling. >>> Types don't restrict anything. They just cannot do that, because type is >>> an >>> abstraction. [ Proof: make each object singleton. q.e.d. ] >> They don't restrict anything?????? You have to be pulling my chain here. Given that type theory is based on mathematics, what "major compromise" or 'restriction' does mathematics ever make/do with anything (think of the Halting problem, Russells' Paradox etc) ?? :-) So the initial claim shows a degree of ignorance. Specifically, being unable to separate a theory from the practical use of that theory. >> Tell that to all the OOP programmers who spend a substantial part of >> their time doing dependency management refactoring _after the >> application is demonstrated to work correctly_. All they are doing is >> overcoming the shortcomings of the OOPLs in order to make the >> application more maintainable. Another initial claim showing quite a degree of ignorance. It is not types, or type theory in general, that cause these problems or work, but the use in OOP of one particular type regime (one that has seen better days) .. To use an analogy, it is like having mathematics and claiming maths is difficult because, although multiplication (x *y) is defined, some regime forces me to write it as x + x + x + ... (y times) . >> One doesn't have that problem with >> executable OOA/D models; when they execute correctly, they are done. > They do it for the sake of re-use. Models based on individual objects have > no validity beyond their direct application purpose. Cars are designed to > go > into production. That much is true. I and colleagues have certainly seen enough Shlaer-Mellor projects in the telecoms sector where the 'models' are not reusable beyond their original reason for conception. > People want to learn. Refactoring (largely based on the type system) is a > cognition process of software construction. It is programming as a > scientific activity. I don't restructure industry systems merely for learning (I have better things to do with my time) . :-) Regards, Steven Perryman
From: H. S. Lahman on 6 Sep 2006 12:22
Responding to Kazakov... >>>This still does not answer the question: what does Car delegate to Drive >>>Train? >> >>All the properties that are logically related to a Drive Train. Without >>delegation the Car has properties like 'horsepower' because it has a >>drive train at that level of abstraction. After the delegation only >>Drive Train has such properties. > > > = car has delegated implementation of these properties to a drive train. > Such properties are still exposed in the car's interface. They are of the > car, while the act of delegation is merely an implementation detail. Not at all. The delegation is essentially just a shift in the level of abstraction when viewing the problem space. At a higher level of abstraction the only identifiable entity to abstract is a 'car'. At a lower level of abstraction one has multiple identifiable entities to abstract, like 'drive train'. Those entities are logically related in the problem space but they are not the same entities at all at that level of abstraction. >>>And "semantics" is not something you could "store", "allocate", "keep" etc. >>>Semantics is a relation between signs and what they represent. If a car >>>represents a drive train, this does not necessary mean that it physically >>>is a drive train. Your representative in the Congress is not you, though >>>you *delegated* to him some of your constitutional rights. When you >>>exercise your rights through him, it does not mean that he lives in your >>>home and wears your socks... >> >>The problem here is fundamental OOA/D abstraction (or abstraction in >>general, for that matter!). A 'car' is a physical entity in the problem >>space that one needs to abstract. How one abstracts it depends on what >>is important about it to the problem in hand. >> >>A car doesn't represent a drive train in the problem space; it >>physically has one _if all one needs to explicitly identify is a 'car'_. >> If I represent the Car as an object without delegation, then I must >>represent the relevant properties it has in the problem space, which >>includes those of its drive train. > > > Properties of a car are independent on whether computerized models of those > are delegated or not. A car from the problem space delegates nothing. It is > absurd to think otherwise, provided, we aren't going to fall into OO > religion, claiming that physical world is OO. To an auto retailer the drive train is an integral part of the notion of 'car' and there is no distinction between them. To the manager of an auto assembly plant the 'drive train' is a completely independent entity whose properties have nothing at all to do with the notion of 'car'. IOW, the manager views 'car' as simply a collection of discrete parts and would never dream of thinking that a 'drive train' is-a 'car'. Therefore the notion of what a 'car' is and what properties it has is very strongly dependent on the context of the problem in hand. IOW, properties are dependent on the conceptual context of the problem. We abstract the entities that are identifiable in the problem space at a level of abstraction that is appropriate to the problem in hand. We abstract them as independent because the delegation occurred when we chose the level of abstraction of the problem space view that rendered them independent. You can represent whatever delegations you want at the OOP level, but for the application to be well-formed in an OOA/D sense every object /must/ be an abstraction of some uniquely identifiable entity in some problem space. Moreover, that entity must have a unique set of /intrinsic/ properties that are not found in other objects (unless a true generalization exists in the problem space where "is-a" applies to all the objects). > > [...] > >>In fact, to "exercise your rights through him" you would have to include >>the Drive Train interface in the Car interface. > > > Sure. Otherwise, delegation would be an implementation detail. Anything not > exposed in the interfaces just does not exist. Your examples illustrate > low-level implementation details. And that is clearly wrong for a paradigm where the primary goal is software maintainability. One wants to minimize the number of places where changes must be made in the face of volatile requirements. So how does the software developer consistently avoid unnecessary edits when requirements change? By employing a fundamental DESIGN paradigm like peer-to-peer collaboration up front in the original design. So there is no "low level implementation" involved at all; it is basic OOA/D. >>>>>>>>IOW, objects collaborate on a peer-to-peer basis. >>>>>>> >>>>>>>OK, that's the same disagreement between us. There is no peers at the >>>>>>>abstraction level of types. You won't get me back down to the ad-hockery of >>>>>>>individual objects... (:-)) >>>>>> >>>>>>Dmitry, I got to ask it: what are you doing on an OO forum if you refuse >>>>>>to accept the most fundamental tenets of OOA/D? >>>>> >>>>>As I said, we have different views on what OO is. This includes A/D. >>>> >>>>An interesting Freudian Typo (A/D vs. OOA/D). B-) >>> >>>It was not a typo, I intentionally used it without OO. Not all A/D is OO, >>>and OO is not exclusively about A/D. >> >>Ok, then my original question still stands: if your A/D is not OOA/D, >>then what are you doing on a forum like comp.object? > > > Are you sure that this forum follows your orthodoxy? (:-)) Even if it did, > I enjoy opinions different from mine. The forum membership is not at issue. The forum subject matter is OOA/D (OOP is addressed by comp.object.programming). Every OOA/D author presenting a basic, general purpose methodology for OOA/D that I have ever read advocates peer-to-peer collaboration. >>>>IMO, whatever you >>>>are doing for A/D clearly isn't OOA/D. That's because you can't do >>>>OOA/D if you restrict your thinking to types. One can make a strong >>>>case for the assertion that the evolution of OOA/D since Smalltalk was >>>>driven in no small part by the need to avoid the foot-shooting that >>>>became apparent when people actually started using the OOPL type systems. >>>> >>>>Types represent a major compromise with hardware models (e.g., explicit >>>>support of procedural message passing). As a result those compromises >>>>make i |