delegation vs. inheritance
in [OOP]
|
From: adaworks on 29 Aug 2006 13:07 "H. S. Lahman" <h.lahman(a)verizon.net> wrote in message news:JBmCg.17882$Qu4.12500(a)trnddc04... > > Not necessarily. The geometrical facts are: (A) both have four sides; (B) for > a square all sides are of the same length; and (C) for a rectangle opposing > sides are the same length but adjacent sides are not. So if one defined > sideLengthN (N = 1..4) for Square, then Rectangle could be a subclass without > any LSP inconsistency in the knowledge attributes. > Perhaps we start with polygon, then inherit quadragons. Now, is a square a kind of rectangle? Seems to be. Is a rectangle a kind of square? Does not seem to be. Is a rhomboid a kind of polygon? Is a parallelagram a kind of rhomboid? Is a rectangle a kind of parallelagram? Is a square descended from all of those? I realize everyone in this forum understands the answers to these questions. For simple shapes, the answers are easy. We need to avoid making to much of the inheritance relationship vis-a-vis the biological model. Biological inheritance giveth and taketh away. Rather than simply adding new properties, as the specialization progresses, we often see properties being deleted, or made inoperable as new species evolve from existing species. The LSP does not hold in biology. I tend to agree that the word "specialization" is more descriptive of what we do in software. When we are modeling, we do generalization. When extending existing code, we tend to specialization. An interesting problem is that no contemporary programming language really lends itself to generalization, once the source code is in place. This conversation began as a discussion of delegation versus inheritance. Considering my previous paragraph, I am still wondering which programming language supports a model of delegation that does not require a call-return implementation. Richard Riehle
From: H. S. Lahman on 30 Aug 2006 10:46 Responding to Adaworks... > This conversation began as a discussion of delegation versus inheritance. > Considering my previous paragraph, I am still wondering which programming > language supports a model of delegation that does not require a call-return > implementation. AFAIK, they all do. All one needs to do is define the delegatee, instantiate a relationship to it, and navigate that relationship during collaborations. For example, in the GoF Strategy pattern the delegation of Strategy is from the Context entity: * R1 1 [Context] ----------------- [Strategy] A | ... Once one has extracted the [Strategy] delegation from [Context], all one has to do is instantiate R1 with a pointer or somesuch to access a particular Strategy from a given Context during a collaboration. But that's too easy, so I have to conclude I don't understand your point. Specifically, what do you mean by "call-return"? ************* There is nothing wrong with me that could not be cured by a capful of Drano. H. S. Lahman hsl(a)pathfindermda.com Pathfinder Solutions http://www.pathfindermda.com blog: http://pathfinderpeople.blogs.com/hslahman "Model-Based Translation: The Next Step in Agile Development". Email info(a)pathfindermda.com for your copy. Pathfinder is hiring: http://www.pathfindermda.com/about_us/careers_pos3.php. (888)OOA-PATH
From: Dmitry A. Kazakov on 30 Aug 2006 11:06 On Wed, 30 Aug 2006 14:46:38 GMT, H. S. Lahman wrote: > Responding to Adaworks... > >> This conversation began as a discussion of delegation versus inheritance. >> Considering my previous paragraph, I am still wondering which programming >> language supports a model of delegation that does not require a call-return >> implementation. > > AFAIK, they all do. All one needs to do is define the delegatee, > instantiate a relationship to it, and navigate that relationship during > collaborations. For example, in the GoF Strategy pattern the delegation > of Strategy is from the Context entity: > > * R1 1 > [Context] ----------------- [Strategy] > A > | > ... > > Once one has extracted the [Strategy] delegation from [Context], all one > has to do is instantiate R1 with a pointer or somesuch to access a > particular Strategy from a given Context during a collaboration. > > But that's too easy, so I have to conclude I don't understand your > point. Specifically, what do you mean by "call-return"? I think Richard meant an automatic generation of wrappers for delegated things. My position is that when this is supported, then delegation = inheritance. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de
From: H. S. Lahman on 31 Aug 2006 11:19 Responding to Kazakov... >>>This conversation began as a discussion of delegation versus inheritance. >>>Considering my previous paragraph, I am still wondering which programming >>>language supports a model of delegation that does not require a call-return >>>implementation. >> >>AFAIK, they all do. All one needs to do is define the delegatee, >>instantiate a relationship to it, and navigate that relationship during >>collaborations. For example, in the GoF Strategy pattern the delegation >>of Strategy is from the Context entity: >> >> * R1 1 >>[Context] ----------------- [Strategy] >> A >> | >> ... >> >>Once one has extracted the [Strategy] delegation from [Context], all one >>has to do is instantiate R1 with a pointer or somesuch to access a >>particular Strategy from a given Context during a collaboration. >> >>But that's too easy, so I have to conclude I don't understand your >>point. Specifically, what do you mean by "call-return"? > > > I think Richard meant an automatic generation of wrappers for delegated > things. I don't see any wrappers. The delegation already exists in the problem space because the delegatee must be identifiable there to abstract it as an object (e.g., a role played by Strategy). IOW, all one does is change the level of abstraction of one's view of the problem space. Once one has identified the delegatee, then all one needs to do is implement a simple association between it and the delegator. In an OO context there are only three ways to do that: passing an object reference in a message, using a pointer referential attribute, or conducting a class search based on explicit object identity. > > My position is that when this is supported, then delegation = inheritance. > Even if one does employ somehow wrappers, all one has is a construct for indirection like Singleton or Facade. So I don't see any generalization. ************* There is nothing wrong with me that could not be cured by a capful of Drano. H. S. Lahman hsl(a)pathfindermda.com Pathfinder Solutions http://www.pathfindermda.com blog: http://pathfinderpeople.blogs.com/hslahman "Model-Based Translation: The Next Step in Agile Development". Email info(a)pathfindermda.com for your copy. Pathfinder is hiring: http://www.pathfindermda.com/about_us/careers_pos3.php. (888)OOA-PATH
From: Dmitry A. Kazakov on 31 Aug 2006 14:52
On Thu, 31 Aug 2006 15:19:31 GMT, H. S. Lahman wrote: > Responding to Kazakov... > >>>>This conversation began as a discussion of delegation versus inheritance. >>>>Considering my previous paragraph, I am still wondering which programming >>>>language supports a model of delegation that does not require a call-return >>>>implementation. >>> >>>AFAIK, they all do. All one needs to do is define the delegatee, >>>instantiate a relationship to it, and navigate that relationship during >>>collaborations. For example, in the GoF Strategy pattern the delegation >>>of Strategy is from the Context entity: >>> >>> * R1 1 >>>[Context] ----------------- [Strategy] >>> A >>> | >>> ... >>> >>>Once one has extracted the [Strategy] delegation from [Context], all one >>>has to do is instantiate R1 with a pointer or somesuch to access a >>>particular Strategy from a given Context during a collaboration. >>> >>>But that's too easy, so I have to conclude I don't understand your >>>point. Specifically, what do you mean by "call-return"? >> >> >> I think Richard meant an automatic generation of wrappers for delegated >> things. > > I don't see any wrappers. The delegation already exists in the problem > space because the delegatee must be identifiable there to abstract it as > an object (e.g., a role played by Strategy). IOW, all one does is > change the level of abstraction of one's view of the problem space. That's why it is no different from inheritance. > Once one has identified the delegatee, then all one needs to do is > implement a simple association between it and the delegator. No. This is the same issue as we have discussed for LSP. There is no *the* delegatee. Delegation is a relation between types, which [types] have potentially unlimited set of instances. > In an OO > context there are only three ways to do that: passing an object > reference in a message, using a pointer referential attribute, or > conducting a class search based on explicit object identity. Implementation details... >> My position is that when this is supported, then delegation = inheritance. > > Even if one does employ somehow wrappers, all one has is a construct for > indirection like Singleton or Facade. So I don't see any generalization. Generalization is that as a type relation delegation is no different from interface implementation. To me it is a form of inheritance [from the interface]. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de |