delegation vs. inheritance
in [OOP]
|
From: Dmitry A. Kazakov on 7 Sep 2006 05:47 On Wed, 06 Sep 2006 16:22:30 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. > > 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. [...] You have to choose an abstraction level. You cannot talk about delegation universally, out of any context. The point is: 1. different abstractions of a car are different per definition. That they possibly abstract the same car is irrelevant. 2. delegation is a property of the given abstraction, and see 1. >>>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. Huh, the thesis you have challenged is actually rephrased "information hiding" principle. If you mean that exposing irrelevant information increases maintainability, then we are indeed in a great disagreement. >>>>>>>>>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). According to Google Groups: comp.object is about "Object-oriented programming and languages." > Every OOA/D author > presenting a basic, general purpose methodology for OOA/D that I have > ever read advocates peer-to-peer collaboration. All depends on what you mean under "peer-to-peer collaboration." In fact, I didn't even attributed it as bad. I just said - it is the lowest possible abstraction level. Clearly, collaboration en masse (=as types) is a higher level abstraction. [*] It is also obvious, that there is nothing below the objects. [**] So what is your objection? Against the level or the implied quality of? ------------- * That means precisely - a higher level abstraction is required to describe such entities, their collaboration and collaboration of the instances of. ** Hence, not just "low", but "lowest." >>>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. > > No, the primary goal of dependency management is to make the 3GL code > more maintainable. That is only necessary at the OOP level because of > the constraints and compromises the 3GL type systems impose that result > in physical coupling. That is simply not a problem at the OOA/D level > because the OOA/D model is not dependent on the implementation language > and good OOA/D practice like peer-to-peer collaboration ensures > maintainability. .... by prohibiting re-use. At this level of abstraction there cannot be any re-use. So what is maintainable? Note that adapting to changes requires re-use, because, as everybody knows, abstractions change so the model you dealt yesterday with is different today. And it is not just re-wired, the only thing you can do with static peers. It is also re-applied, the peers are re-mapped, new peers emerge. How are you supposed to describe this without types? BTW, I really don't understand your position on this issue. Let me elaborate this a bit. There are people who reject types, but they don't reject higher-level abstractions. (I don't consider trolls) So they try to bury types into objects. This naturally leads to types as objects, for objects take the role of types. Feasibility of such systems is another question, but I can understand their intent. Another approach could be to have an infinite hierarchy of languages, where would-be types in nGL were first-class objects in n+1GL. Not nice, but clearly consistent. But your position puzzles
From: H. S. Lahman on 7 Sep 2006 12:01 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. > > > [...] > You have to choose an abstraction level. You cannot talk about delegation > universally, out of any context. > > The point is: > > 1. different abstractions of a car are different per definition. That they > possibly abstract the same car is irrelevant. One needs to choose the appropriate level of abstracting the problem space before one defines objects and different abstractions of the problem space will be different. But the problem space is definitely not irrelevant to OOA/D. > 2. delegation is a property of the given abstraction, and see 1. How is delegation a property? It is a conceptual activity whereby one subdivides an entity viewed at a high level of abstraction into individual entities viewed at a lower level of abstraction. More relevant to the discussion, once one identifies a delegation, abstracts it, and implements it, there will be no evidence of the higher level view in the implementation. IOW, there is no way to tell if delegation was applied in when abstracting the problem space. Therefore delegation is a design activity that transcends implementation at the 3GL level. >>>>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. > > > Huh, the thesis you have challenged is actually rephrased "information > hiding" principle. If you mean that exposing irrelevant information > increases maintainability, then we are indeed in a great disagreement. Exposing another object's interface is unnecessary information exposure. That interface only needs to be exposed once -- in the object with the responsibilities. Exposing it redundantly in middlemen objects simply decreases the maintainability of the application, which is why OOA/D militantly practices peer-to-peer collaboration. >>Every OOA/D author >>presenting a basic, general purpose methodology for OOA/D that I have >>ever read advocates peer-to-peer collaboration. > > > All depends on what you mean under "peer-to-peer collaboration." In fact, I > didn't even attributed it as bad. I just said - it is the lowest possible > abstraction level. Clearly, collaboration en masse (=as types) is a higher > level abstraction. [*] It is also obvious, that there is nothing below the > objects. [**] So what is your objection? Against the level or the implied > quality of? You have been advocating an agent approach: talks to talks to [Client] --------> [Delegator] -----------> [Delegatee] where the client accesses the Delegator interface on a peer-to-peer basis and the Delegator then re-dispatches the request to the Delegatee who actually has the responsibilities. You have also agreed that to do that the Delegatee interface must be exposed in the Delegator interface in order to allow the Client to access the properties. That makes Delegator an unnecessary middleman because the collaboration should be directly between Client and Delegatee. >>>>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. >> >>No, the primary goal of dependency management is to make the 3GL code >>more maintainable. That is only necessary at the OOP level because of >>the constraints and compromises the 3GL type systems impose that result >>in physical coupling. That is simply not a problem at the OOA/D level >>because the OOA/D model is not dependent on the implementation language >>and good OOA/D practice like peer-to-peer collaboration ensures >>maintainability. > > > ... by prohibiting re-use. At this level of abstraction there cannot be any > re-use. So what is maintainable? Note that adapting to changes requires > re-use, because, as everybody knows, abstractions change so the model you > dealt yesterday with is different today. And it is not just re-wired, the > only thing you can do with static peers. It is also re-applied, the peers > are re-mapped, new peers emerge. How are you supposed to describe this > without types? There is no reuse in OOA/D solutions???? We reuse entire subsystems, for Pete's sake! I really don't know where you are getting this stuff. For example, what do you think the GoF
From: Don Roby on 7 Sep 2006 19:34 Dmitry A. Kazakov wrote: > On Wed, 06 Sep 2006 16:22:30 GMT, H. S. Lahman wrote: > > >> >>The forum membership is not at issue. The forum subject matter is OOA/D >>(OOP is addressed by comp.object.programming). > > > According to Google Groups: comp.object is about "Object-oriented > programming and languages." > > Moreover, comp.object.programming doesn't seem to exist. I'd say this group is about OO generally.
From: Dmitry A. Kazakov on 8 Sep 2006 04:58 On Thu, 07 Sep 2006 16:01:02 GMT, H. S. Lahman wrote: > Responding to Kazakov... > >> [...] >> You have to choose an abstraction level. You cannot talk about delegation >> universally, out of any context. >> >> The point is: >> >> 1. different abstractions of a car are different per definition. That they >> possibly abstract the same car is irrelevant. > > One needs to choose the appropriate level of abstracting the problem > space before one defines objects and different abstractions of the > problem space will be different. But the problem space is definitely > not irrelevant to OOA/D. > >> 2. delegation is a property of the given abstraction, and see 1. > > How is delegation a property? It is a conceptual activity whereby one > subdivides an entity viewed at a high level of abstraction into > individual entities viewed at a lower level of abstraction. Activity? Then it is outside both the abstraction and the problem space. For example, playing golf while thinking about cars is an activity. My position is that unlike golf, delegation lives in the abstraction and nowhere else. >> Huh, the thesis you have challenged is actually rephrased "information >> hiding" principle. If you mean that exposing irrelevant information >> increases maintainability, then we are indeed in a great disagreement. > > Exposing another object's interface is unnecessary information exposure. > That interface only needs to be exposed once -- in the object with the > responsibilities. Exposing it redundantly in middlemen objects simply > decreases the maintainability of the application, which is why OOA/D > militantly practices peer-to-peer collaboration. Objects without interfaces are useless. In which form delegation is exposed to the client? If it does not, then there is no delegation for the client. If it is then it must have an interface. >>>Every OOA/D author >>>presenting a basic, general purpose methodology for OOA/D that I have >>>ever read advocates peer-to-peer collaboration. >> >> All depends on what you mean under "peer-to-peer collaboration." In fact, I >> didn't even attributed it as bad. I just said - it is the lowest possible >> abstraction level. Clearly, collaboration en masse (=as types) is a higher >> level abstraction. [*] It is also obvious, that there is nothing below the >> objects. [**] So what is your objection? Against the level or the implied >> quality of? > > You have been advocating an agent approach: > > talks to talks to > [Client] --------> [Delegator] -----------> [Delegatee] > > where the client accesses the Delegator interface on a peer-to-peer > basis and the Delegator then re-dispatches the request to the Delegatee > who actually has the responsibilities. You have also agreed that to do > that the Delegatee interface must be exposed in the Delegator interface > in order to allow the Client to access the properties. That makes > Delegator an unnecessary middleman because the collaboration should be > directly between Client and Delegatee. Yes, because otherwise there is no delegation visible to the clients. Invisible things do not exist. That's the information hiding principle. >> ... by prohibiting re-use. At this level of abstraction there cannot be any >> re-use. So what is maintainable? Note that adapting to changes requires >> re-use, because, as everybody knows, abstractions change so the model you >> dealt yesterday with is different today. And it is not just re-wired, the >> only thing you can do with static peers. It is also re-applied, the peers >> are re-mapped, new peers emerge. How are you supposed to describe this >> without types? > > There is no reuse in OOA/D solutions???? We reuse entire subsystems, > for Pete's sake! I really don't know where you are getting this stuff. > For example, what do you think the GoF "Design Patterns" book > represents other than design reuse? Pattern is NOT software. If you mean reuse of designs, then it is a way different topic, and, even less I can understand how designs as higher-level abstractions could be re-used while considering *individual* objects. It is like re-using an environmental solution by collecting cuttings on the logging plant... How do you know if a pattern X is applicable to the problem Y? What *type* of solutions X represents? You can't get rid of types. >> BTW, I really don't understand your position on this issue. Let me >> elaborate this a bit. There are people who reject types, but they don't >> reject higher-level abstractions. (I don't consider trolls) So they try to >> bury types into objects. This naturally leads to types as objects, for >> objects take the role of types. Feasibility of such systems is another >> question, but I can understand their intent. Another approach could be to >> have an infinite hierarchy of languages, where would-be types in nGL were >> first-class objects in n+1GL. Not nice, but clearly consistent. But your >> position puzzles me. > > I have no problem with type systems per se. They are very useful for > implementing software designs at the 3GL level because they make the > constraints of the hardware computational models relatively transparent. > They are even more useful for designing 3GLs, especially OOPLs. But > they were designed around those constraints that exist at the 3GL level > of computation abstraction in the same sense that Codd's relational data > model was constructed around the constraints of hard disk storage. The > math may have evolved into a more general expression since, but the > intrinsic structure remains. > > At the OOA level one is completely independent of the computing > environment and largely so at the OOD level. So one employs different > paradigms for abstraction, notably an object view and pure set > membership view rather than a <procedural> interface view. At that > level of design abstraction the type systems are irrelevant. So to try > to express OOA/D in terms of manipulating types is like the tail wagging > the dog. Should I read it as OOA/D be better than math? In what sense? No mathematical model is capable to describe UML diagrams? > Note that translationists routinely transform UML OOA models directly > into non-OOPL code like C where the the closest type abstraction to an > object is a union.
From: H. S. Lahman on 8 Sep 2006 10:53
Responding to Kazakov... >>>The point is: >>> >>>1. different abstractions of a car are different per definition. That they >>>possibly abstract the same car is irrelevant. >> >>One needs to choose the appropriate level of abstracting the problem >>space before one defines objects and different abstractions of the >>problem space will be different. But the problem space is definitely >>not irrelevant to OOA/D. >> >> >>>2. delegation is a property of the given abstraction, and see 1. >> >>How is delegation a property? It is a conceptual activity whereby one >>subdivides an entity viewed at a high level of abstraction into >>individual entities viewed at a lower level of abstraction. > > > Activity? Then it is outside both the abstraction and the problem space. > For example, playing golf while thinking about cars is an activity. My > position is that unlike golf, delegation lives in the abstraction and > nowhere else. Huh? It is a conceptual <design> activity that is one aspect of the broader conceptually <design> activity of abstracting a problem space. >>>Huh, the thesis you have challenged is actually rephrased "information >>>hiding" principle. If you mean that exposing irrelevant information >>>increases maintainability, then we are indeed in a great disagreement. >> >>Exposing another object's interface is unnecessary information exposure. >> That interface only needs to be exposed once -- in the object with the >>responsibilities. Exposing it redundantly in middlemen objects simply >>decreases the maintainability of the application, which is why OOA/D >>militantly practices peer-to-peer collaboration. > > > Objects without interfaces are useless. In which form delegation is exposed > to the client? If it does not, then there is no delegation for the client. > If it is then it must have an interface. I didn't say the object doesn't need an interface. What I am saying is that one doesn't need the same properties to be exposed in the interfaces of more than one object. That leads to redundant changes when the interface changes. IOW, those properties should only be exposed in the interface of the object that owns them. >>>>Every OOA/D author >>>>presenting a basic, general purpose methodology for OOA/D that I have >>>>ever read advocates peer-to-peer collaboration. >>> >>>All depends on what you mean under "peer-to-peer collaboration." In fact, I >>>didn't even attributed it as bad. I just said - it is the lowest possible >>>abstraction level. Clearly, collaboration en masse (=as types) is a higher >>>level abstraction. [*] It is also obvious, that there is nothing below the >>>objects. [**] So what is your objection? Against the level or the implied >>>quality of? >> >>You have been advocating an agent approach: >> >> talks to talks to >>[Client] --------> [Delegator] -----------> [Delegatee] >> >>where the client accesses the Delegator interface on a peer-to-peer >>basis and the Delegator then re-dispatches the request to the Delegatee >>who actually has the responsibilities. You have also agreed that to do >>that the Delegatee interface must be exposed in the Delegator interface >>in order to allow the Client to access the properties. That makes >>Delegator an unnecessary middleman because the collaboration should be >>directly between Client and Delegatee. > > > Yes, because otherwise there is no delegation visible to the clients. > Invisible things do not exist. That's the information hiding principle. What you are talking about is communication, not delegation. The delegation exists as soon as one abstracts the [Delegatee] object from the problem space. Once the properties are moved to [Delegatee] we should have talks to [Client] -------------> [Delegatee] However, that does not change the orthogonal nature of the logical relationships that capture the rules and policies of participation in the communication so the Class Model remains: [Client] | * | | R1 | | is logically related to | [Delegator] | * | | R2 | | plays the role of | 1 [Delegatee] where the logical relationship between delegator and delegatee is captured by the R2 relationship. The Client is still constrained to talk only to the Delegatee that is reachable via the R1 relationship. But once the delegation has been defined that R2 relationship is no different than any other association in the Class Model and the relationship path for peer-to-peer communication is navigated exactly the same way any other relationship path would be navigated. >>>... by prohibiting re-use. At this level of abstraction there cannot be any >>>re-use. So what is maintainable? Note that adapting to changes requires >>>re-use, because, as everybody knows, abstractions change so the model you >>>dealt yesterday with is different today. And it is not just re-wired, the >>>only thing you can do with static peers. It is also re-applied, the peers >>>are re-mapped, new peers emerge. How are you supposed to describe this >>>without types? >> >>There is no reuse in OOA/D solutions???? We reuse entire subsystems, >>for Pete's sake! I really don't know where you are getting this stuff. >> For example, what do you think the GoF "Design Patterns" book >>represents other than design reuse? > > > Pattern is NOT software. If you mean reuse of designs, then it is a way > different topic, and, even less I can understand how designs as > higher-level abstractions could be re-used while considering *individual* > objects. It is like re-using an environmental solution by collecting > cuttings on the logging plant... How do you know if a pattern X is > applicable to the problem Y? What *type* of solutions X represents? You > can't get rid of types. I don't know how to respond to this. That the GoF book's major contribution lay in identifying design reuse for specific dynamic situations seems, as Norbert Weiner was fond of saying, intuitively obvious. >>>BTW, I really don't understand your position on this issue. Let me >>>elaborate this a bit. There are people who reject types, but they don't >>>reject higher-level abstractions. (I don't consider trolls) So they try to >>>bury types into objects. This naturally leads to types as objects, for >>>objects ta |