delegation vs. inheritance
in [OOP]
|
From: Dmitry A. Kazakov on 9 Sep 2006 09:30 On Fri, 08 Sep 2006 14:53:35 GMT, H. S. Lahman wrote: > 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. Anyway a design activity is not design, so, according to you delegation falls out. > 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 is a very serious claim. In other words, only one car needs a steering wheel. Others will have reins, no, actually the very concept that you sit in and hold something to control the thing is no-no. Surely you won't have any problem with LSP (=driving license), because the will be no driving. >>>>>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] And exactly this is just a communication, so far. You have just "talk to." Delegation is more than that. And properties wasn't moved anywhere, they are shared. What was moved is implementation of these properties. >> 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. But how intuition works in this case? My point is that GoFs are obvious to you because they match the concepts (=types) you have in your head. Similarly you have a concept of steering wheels, which most of cars match. That's why you can drive these cars. Type is a formalization of this mechanics, which is quite universal and by no means is limited to 3GL niche. >> Should I read it as OOA/D be better than math? In what sense? No >> mathematical model is capable to describe UML diagrams? > > Where do you get that interpretation? Both are ultimately based on set > theory. OOA/D just provides more abstraction and generality than the > 3GLs because it isn't constrained by the computing space environment. 1. Independence on computing environment does not imply either better or higher abstraction. The issues to consider are completeness, power, decidability. 2. Why do you think that UML covers (is equivalent to) a wider class of computational systems than 3GL? I have strong doubts about it. 3. Further, I challenge the thesis that UML is more independent than all 3GL, provided, independence were treated as portability. >>>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. (Some even generate Assembly directly.) The point >>>being that one does not need type systems at all to do OO development. >>>They are simply a convenient implementation mechanism at the 3GL level. >> >> But existence of a compiler is absolutely irrelevant to the issue whether a >> language has to be typed. As I said before, UML, if will not die soon, will >> be typed. Note UML, not C. > > Let me see if I understand this. UML employs class systems rather than > type systems and has been successfully used for nearly two decades to > build OO software. (Even longer if one includes its predecessor > notations.) Yet that is all just inexplicable good luck because all > languages must be typed and, consequently, UML is flawed and doomed to > fail.
From: H. S. Lahman on 9 Sep 2006 12:01 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. > > > Anyway a design activity is not design, so, according to you delegation > falls out. So design is a matter of Spontaneous Revelation From On High? >>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 is a very serious claim. In other words, only one car needs a steering > wheel. Others will have reins, no, actually the very concept that you sit > in and hold something to control the thing is no-no. Surely you won't have > any problem with LSP (=driving license), because the will be no driving. OK, I was imprecise. I should have said, "...interfaces of objects from different classes not involved in a generalization." The point is an OOA/D Class Model should be normalized using the same RDM-based techniques as one normalizes a Data Model. >>>>>>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] > > > And exactly this is just a communication, so far. You have just "talk to." > Delegation is more than that. And properties wasn't moved anywhere, they > are shared. What was moved is implementation of these properties. And communication is pretty much what collaboration is about. Objects collaborate by sending one another messages. But you talk to (send a message to) an interface. The point is that once the Delegatee is defined the Client talks directly to it rather than to the Delegator. As I pointed out in the elided text, the relationship path through Delegator then only serves to ensure Client is talking to the right Delegatee. >>>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. > > > But how intuition works in this case? My point is that GoFs are obvious to > you because they match the concepts (=types) you have in your head. > Similarly you have a concept of steering wheels, which most of cars match. > That's why you can drive these cars. Type is a formalization of this > mechanics, which is quite universal and by no means is limited to 3GL > niche. What you are describing are classes, not types. But we're going in circles. More to the point, the issue here was design reuse, not classes vs. types. >>>Should I read it as OOA/D be better than math? In what sense? No >>>mathematical model is capable to describe UML diagrams? >> >>Where do you get that interpretation? Both are ultimately based on set >>theory. OOA/D just provides more abstraction and generality than the >>3GLs because it isn't constrained by the computing space environment. > > > 1. Independence on computing environment does not imply either better or > higher abstraction. The issues to consider are completeness, power, > decidability. Au contraire! It clearly implies a higher level of abstraction. That's one of the things abstraction does -- it provides independence of specific implementation details. > > 2. Why do you think that UML covers (is equivalent to) a wider class o
From: Dmitry A. Kazakov on 11 Sep 2006 06:17 On Sat, 09 Sep 2006 16:01:38 GMT, H. S. Lahman wrote: > 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. >> >> Anyway a design activity is not design, so, according to you delegation >> falls out. > > So design is a matter of Spontaneous Revelation From On High? For the program being designed, yes, it is. Otherwise it could design itself. >>>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 is a very serious claim. In other words, only one car needs a steering >> wheel. Others will have reins, no, actually the very concept that you sit >> in and hold something to control the thing is no-no. Surely you won't have >> any problem with LSP (=driving license), because the will be no driving. > > OK, I was imprecise. I should have said, "...interfaces of objects from > different classes not involved in a generalization." What is generalized then? If interfaces are object-specific, they aren't interfaces to me. A socket is an interface. If I am required to stretch for a soldering iron each time I need to change a bulb, sorry, that isn't a good design. > The point is an > OOA/D Class Model should be normalized using the same RDM-based > techniques as one normalizes a Data Model. Implementation details again. >>>Once the properties are moved to [Delegatee] we should have >>> >>> talks to >>>[Client] -------------> [Delegatee] >> >> And exactly this is just a communication, so far. You have just "talk to." >> Delegation is more than that. And properties wasn't moved anywhere, they >> are shared. What was moved is implementation of these properties. > > And communication is pretty much what collaboration is about. Objects > collaborate by sending one another messages. But you talk to (send a > message to) an interface. The point is that once the Delegatee is > defined the Client talks directly to it rather than to the Delegator. That exposes the Delegatee. It is a bad thing, and for all, it is not a delegation, because the client becomes aware of the process or "routing." > As I pointed out in the elided text, the relationship path through > Delegator then only serves to ensure Client is talking to the right > Delegatee. No, it serves the purpose of abstraction the Delegatee. When my computer talks to comp.object it does not need to go after the server hosting it. There might be no any. It talks to the socket library and that is. > What you are describing are classes, not types. But we're going in > circles. More to the point, the issue here was design reuse, not > classes vs. types. Classes are just closures of types sets. When I am talking about types I mean a types system. Which includes values, types, types of types, values of types, sets of values, sets of types and so on, with some types algebra upon it. If you get rid of types, the rest would be isolated values interconnected by some ad-hoc network of subprogram calls. Welcome back to mid 60's! Now substitute "object" for "value", "collaboration" for "call"... >>>>Should I read it as OOA/D be better than math? In what sense? No >>>>mathematical model is capable to describe UML diagrams? >>> >>>Where do you get that interpretation? Both are ultimately based on set >>>theory. OOA/D just provides more abstraction and generality than the >>>3GLs because it isn't constrained by the computing space environment. >> >> 1. Independence on computing environment does not imply either better or >> higher abstraction. The issues to consider are completeness, power, >> decidability. > > Au contraire! It clearly implies a higher level of abstraction. That's > one of the things abstraction does -- it provides independence of > specific implementation details. Ah, but these must be ALL details of interest. You've forgot the problem space. An abstraction, like memory cell, could be extremely independent from any environment (all electronic computers would have memory cells) and simultaneously to low-level to abstract anything decent. >> 2. Why do you think that UML covers (is equivalent to) a wider class of >> computational systems than 3GL? I have strong doubts about it. > > It does because one of the reviewer tests of an UML OOA model is that > the model could be implemented without change as a manual system. The > OOA model for a POS order entry system will look exactly the same > whether it is instantiated in a modern browser-based environment as it > would if it were implemented as an early 20th century Sears catalogue > with mail-in order form. That does not prove the thesis. You have to show that there are computational systems for which there exists a compiler from UML, but a compiler from (any) 3GL cannot be even written. >> 3. Further, I challenge the thesis that UML is more independent than all >> 3GL, provided, independence were treated as portability. > > Of course it is portable. I can implement a UML model with any 3GL on > any platform without modification of the model. MDA transformation > engines provide this portability routinely in R-T/E. In what sense it is more portable than the host 3GL language? >> I meant
From: H. S. Lahman on 11 Sep 2006 11:59 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. >>> >>>Anyway a design activity is not design, so, according to you delegation >>>falls out. >> >>So design is a matter of Spontaneous Revelation From On High? > > > For the program being designed, yes, it is. Otherwise it could design > itself. Alas, I am tuned to the wrong channel, then. I have to execute a number of intellectual activities -- one of which is identifying delegations in the problem space -- in order to create a software design. >>>>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 is a very serious claim. In other words, only one car needs a steering >>>wheel. Others will have reins, no, actually the very concept that you sit >>>in and hold something to control the thing is no-no. Surely you won't have >>>any problem with LSP (=driving license), because the will be no driving. >> >>OK, I was imprecise. I should have said, "...interfaces of objects from >>different classes not involved in a generalization." > > > What is generalized then? If interfaces are object-specific, they aren't > interfaces to me. A socket is an interface. If I am required to stretch for > a soldering iron each time I need to change a bulb, sorry, that isn't a > good design. Generalization describes a set of entities whose nature is fundamentally the same but whose members can be grouped into subsets with unique detailed specializations. Cars and Drive Trains are not fundamentally the same. >>The point is an >>OOA/D Class Model should be normalized using the same RDM-based >>techniques as one normalizes a Data Model. > > > Implementation details again. You do not consider normalization a design activity?!? >>>>Once the properties are moved to [Delegatee] we should have >>>> >>>> talks to >>>>[Client] -------------> [Delegatee] >>> >>>And exactly this is just a communication, so far. You have just "talk to." >>>Delegation is more than that. And properties wasn't moved anywhere, they >>>are shared. What was moved is implementation of these properties. >> >>And communication is pretty much what collaboration is about. Objects >>collaborate by sending one another messages. But you talk to (send a >>message to) an interface. The point is that once the Delegatee is >>defined the Client talks directly to it rather than to the Delegator. > > > That exposes the Delegatee. It is a bad thing, and for all, it is not a > delegation, because the client becomes aware of the process or "routing." Of course it exposes Delegatee! Once the delegation is recognized and abstracted the Delegatee is a peer object to Client and Delegator. More to the point, all three have unique responsibilities that are not shared with any of the others. So to access Delegatee's responsibilities on a peer-to-peer basis, they have to be exposed to Client. >>As I pointed out in the elided text, the relationship path through >>Delegator then only serves to ensure Client is talking to the right >>Delegatee. > > > No, it serves the purpose of abstraction the Delegatee. When my computer > talks to comp.object it does not need to go after the server hosting it. > There might be no any. It talks to the socket library and that is. Thanks for an analogy that makes my point. B-) Actually, YOU are sending a message on a peer-to-peer basis to comp.object. The various mechanisms you are talking about are merely vehicles for delivering the message to the right place. The entities along the way -- computers, network ports, routers, proxies, servers, etc. -- are semantically irrelevant to the collaboration between you and comp.object. IOW, that chain of entities just provides placeholders in a relationship path between You and comp.object. The navigation mechanisms are different in detail but provide the same service as a chain of pointers in an OO application that passes through Delegator without it knowing where you are going. >>What you are describing are classes, not types. But we're going in >>circles. More to the point, the issue here was design reuse, not >>classes vs. types. > > > Classes are just closures of types sets. When I am talking about types I > mean a types system. Which includes values, types, types of types, values > of types, sets of values, sets of types and so on, with some types algebra > upon it. If you get rid of types, the rest would be isolated values > interconnected by some ad-hoc network of subprogram calls. Welcome back to > mid 60's! Now substitute "object" for "value", "collaboration" for > "call"... You really have to get out more. There is a whole world of software design beyond 3GL type systems. >>>>>Should I read it as OOA/D be better than math? In what sense? No >>>>>mathematical model is capable to describe UML diagrams? >>>> >>>>Where do you get that interpretation? Both are ultimately based on set >>>>theory. OOA/D just provides more abstraction and generality than the >>>>3GLs because it isn't constrained by the computing space environment. >>> >>>1. Independence on computing environment does
From: Dmitry A. Kazakov on 12 Sep 2006 06:04
On Mon, 11 Sep 2006 15:59:50 GMT, H. S. Lahman wrote: > Responding to Kazakov... > >>>>>Huh? It is a conceptual <design> activity that is one aspect of the >>>>>broader conceptually <design> activity of abstracting a problem space. >>>> >>>>Anyway a design activity is not design, so, according to you delegation >>>>falls out. >>> >>>So design is a matter of Spontaneous Revelation From On High? >> >> For the program being designed, yes, it is. Otherwise it could design >> itself. > > Alas, I am tuned to the wrong channel, then. I have to execute a number > of intellectual activities -- one of which is identifying delegations in > the problem space -- in order to create a software design. But the activity of identifying delegation is still not delegation itself. You identify some X in the problem space, which is represented as Y in the solution space. Neither X or activity is delegation. Delegation is Y. >>>>>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 is a very serious claim. In other words, only one car needs a steering >>>>wheel. Others will have reins, no, actually the very concept that you sit >>>>in and hold something to control the thing is no-no. Surely you won't have >>>>any problem with LSP (=driving license), because the will be no driving. >>> >>>OK, I was imprecise. I should have said, "...interfaces of objects from >>>different classes not involved in a generalization." >> >> What is generalized then? If interfaces are object-specific, they aren't >> interfaces to me. A socket is an interface. If I am required to stretch for >> a soldering iron each time I need to change a bulb, sorry, that isn't a >> good design. > > Generalization describes a set of entities whose nature is fundamentally > the same but whose members can be grouped into subsets with unique > detailed specializations. Cars and Drive Trains are not fundamentally > the same. A-ha, but the above is in fact the essence of the radical "relational" view. This is a total denial of behavior, because objects are considered mechanically composed out of members. Who is against OO here? (:-)) No, that won't bring you anywhere. Because a simple argument against it, is that both Cars and Drive Trains consists of elementary particles, so they must be fundamentally same. You cannot identify elementary particles, hence you cannot any conglomeration of. >>>The point is an >>>OOA/D Class Model should be normalized using the same RDM-based >>>techniques as one normalizes a Data Model. >> >> Implementation details again. > > You do not consider normalization a design activity?!? I don't consider any activity, because it is outside solution space. We should not mix objects and subjects. Delegation is a subject of design, it is an artefact of design. Being normalized is a property of some design. Normalization is an activity that transforms one design to another. You cannot claim that Inc is a number. Numbers are 1, 2, 3. Among them 4 is an incremented 3. Also Inc is a "numeric activity." If X=3 and Y=4, then we could say that one property of this design is that Y is an incremented X. >>>>>Once the properties are moved to [Delegatee] we should have >>>>> >>>>> talks to >>>>>[Client] -------------> [Delegatee] >>>> >>>>And exactly this is just a communication, so far. You have just "talk to." >>>>Delegation is more than that. And properties wasn't moved anywhere, they >>>>are shared. What was moved is implementation of these properties. >>> >>>And communication is pretty much what collaboration is about. Objects >>>collaborate by sending one another messages. But you talk to (send a >>>message to) an interface. The point is that once the Delegatee is >>>defined the Client talks directly to it rather than to the Delegator. >> >> That exposes the Delegatee. It is a bad thing, and for all, it is not a >> delegation, because the client becomes aware of the process or "routing." > > Of course it exposes Delegatee! Once the delegation is recognized and > abstracted the Delegatee is a peer object to Client and Delegator. More > to the point, all three have unique responsibilities that are not shared > with any of the others. So to access Delegatee's responsibilities on a > peer-to-peer basis, they have to be exposed to Client. But that isn't delegation in the solution space! When I have 3 and 4 as the solution, it is no matter how I managed to get 4. Did I incremented 3? Or somebody advised me that 4 was such a good number? It is no matter now, all knowledge about it is gone, and for all, is irrelevant, because it is *the* solution. There is nothing beyond that. Incrementing would become a part of the solution only if I had published it as Inc(3). Only then somebody looking at this, would say, a-ha, that must be incrementing. >>>As I pointed out in the elided text, the relationship path through >>>Delegator then only serves to ensure Client is talking to the right >>>Delegatee. >> >> No, it serves the purpose of abstraction the Delegatee. When my computer >> talks to comp.object it does not need to go after the server hosting it. >> There might be no any. It talks to the socket library and that is. > > Thanks for an analogy that makes my point. B-) > > Actually, YOU are sending a message on a peer-to-peer basis to > comp.object. The various mechanisms you are talking about are merely > vehicles for delivering the message to the right place. The entities > along the way -- computers, network ports, routers, proxies, servers, > etc. -- are semantically irrelevant to the collaboration between you and > comp.object. IOW, that chain of entities just provides placeholders in > a relationship path between You and comp.object. The navigation > mechanisms are different in detail but provide the same service as a > chain of pointers in an OO application that passes through Delegator > without it knowing where you are going. And delegation is a vehicle to emulate a peer-to-peer connection by replacing client->delegatee relation with client->delegator [->delegatee]. Transitivity of this relation does not mean that the relation does not exist. >>>>1. Independence on computing environment does |