delegation vs. inheritance
in [OOP]
|
From: AndrewMcDonagh on 3 Aug 2006 18:06 adaworks(a)sbcglobal.net wrote: > "Thomas Kowalski" <th-ko(a)gmx.de> wrote in message > news:1154599408.592501.29750(a)b28g2000cwb.googlegroups.com... >> Hi everybody, >> >> recently I was thinking about the concepts of delegation and >> inheritance. >> > This would be a good opportunity for some of the experts in this > forum to elucidate on delegation versus inheritance. At the > theoretical level, we can model it. How is it actually implemented > in languages that don't explicitly support it? C++? Eiffel? Ada? > Smalltalk (well that one is easy, I guess). Java? > > Richard Riehle > > doesn't support it? I take it you mean the language handles the delgation for you as in something like.... (psuedo code) class Callee delegatesTo Delegate extends BaseCallee{ } class Delegate { printHello() } class Test { main() { callee = new Callee(); callee.printHello(); } }
From: Rick Elbers on 4 Aug 2006 15:17 Op Thu, 03 Aug 2006 14:58:39 GMT schreef "H. S. Lahman" <h.lahman(a)verizon.net>: Dear mr Lahman, I alsway read your posts. This one I have a few comments that might sharpen the whole discussion.. >Responding to Kowalski... > >> recently I was thinking about the concepts of delegation and >> inheritance. >> My idea was to simplify huge classes by dividing them in a base class >> and additional class that provide other attributes / aspects / >> functionality. This way it would be possible to create small >> customizable classes easily and reduce complexity. Since I am using C++ >> most of the time multiple inheritance is no problem and different >> "mixes" of aspects could be realized. > >While inheritance and delegation are often used together, such as in >most of the GoF Design patterns, they are quite different things. > >Inheritance is simply a <rather simple> set of rules for determining >what properties a particular member of the root class actually has. >That is very handy for generalization/specialization where the same >basic entity can come in different flavors that have a few unique >properties. I am sorry to say but I really think this is a misconception. Inheritance is ment to support behavioral relations of the type "is a". In the real world "is a" doesnt mean having a few unique properties imho. In fact every class "has " properties. Pointing to delegation. Some have more others have less, in fact thats secundair to their entity and resposibilities and certainly to their inheritance tree. We can put it in a more filosofical way: something or someone is characterized by: 1) What it does. 2) What is has. Maybe its another Europe USA kind of thing:-) > OO subclassing and inheritance are defined in a manner that >also allows polymorphic access of the /common/ properties. This very surely is wrong even at the implementation level. Polymorhpic behavior is certainly not mainly their to support polymorphic access of common properties. Instead its their for common access to polymorphic behavior. For instance ( in an old msdn example) We have beasts that eat food. But we have food for carnivors, for omnivors etc. Each eat different food, but all of them eat(food). > However, a >member of every leaf subclass is always a member of the root superclass, >hence the appellation is-a. > ????? this is meaningless. Is a has a much stronger connotation in normal language then what you propose here. Skipped rest...enough for now.. > >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: Rick Elbers on 4 Aug 2006 15:27 Op 3 Aug 2006 07:51:27 -0700 schreef "Thomas Kowalski" <th-ko(a)gmx.de>: >Hallo Rick, >thanks for your answer! > >> Might I suggest a little ooa/d before you go into technical >> refactoring like this ? > >Yes, you might :) Although I am programming already quite long, I never >really tried to explore the concepts of OO enough it seems. Most of my >code looks like ugly c-style code. Therefore I am trying now to grasp >as much of the "real" OO as possible with the goal to make my code more >easy to understand. Ok start with cutting all technical things and talk talk talk about your domain of application. > >> If you have huge classes probably your problem >> domain is insufficiently analysed and their is not sufficient "domain >> language" to talk about different use case realizations of your >> software. In code that shows like a few monsterous classes or like >> a few monsterous classes delegating everything out( facades). > >Well, the software I am currently working on is settled in computer >graphics. It's a high performance calculation software. Therefore some >concepts of business OOA/D are difficult to apply for me. Please elaborate. The more astonishing oo applications even in the start time of ooa/d where in this sector so it might be more easy to find good domain references then you think. >Basicly I am working on the assumption that an object encapsulates the >methodes to manipulate itself, with might be not really right on second >thought. > In my experience Its always right. Sorry to say it that brutal but believe me the tension that it brings helps you in the right way most often >> You might miss the whole point about inheritance/delegation. > >I guess you are right. I treat inheritance like a way to add >functionality to a class and "group" it this way. > >> Instead try to concentrate on behavior first( or as you call it functionality) >> Attributes/aspects should not drive design but should be encapsulated >> , and that encapsulation is a driving force of your design. > >The way I understand this is: Instead of (over)-using inheritance and >delegation rather try to create a seperate class managing the >additional functionality. Is that correct? > Difficult to say. You first need more firm ground as to the objects in your problem domain. Also you still define your domain pretty technical. You might delve much deeper into the real world application of your software. I guess you experience tension in your design after encapsulating obvious behaviors into obvious domain objects. Thats a good start. Define as many strong independent objects as you can BEFORE going into scenario's or technical implemenation detail( which often is a like). Dont bother about relations between objects at all at first. You will see then that some rather obvious relations for behaviors arise. That kind of relations at the behavioral level can be considered ok as long as they dont compromise the firm object identity that you established upfront... Enfin...you can imagine how this works. Inheritance, delegation and a multitude of other relations can be just the resultant of good ooa/d, but thats not invertible..:-) >> Mixins is a nice implementation certainly when you have clients who >> only receive one of the mixins instead of the whole monster. > >Basicly I want to use it to provide a way to safe memory ressources in >case application that base on a similar datastructure are merged to one >application. This way "customized" classes can be created and "boxed" >on the former border between the two applications. > >Regards, >Thomas Kowalski Rick
From: adaworks on 6 Aug 2006 03:35 "AndrewMcDonagh" <newsamd(a)amc.com> wrote in message news:eats0p$ps0$1(a)news.freedom2surf.net... > > Regarding language support for delegation, you wrote: > doesn't support it? > > I take it you mean the language handles the delgation for you as in something > like.... > At least one model of delegation works like this: A pure delegator forwards a request for action to a delegatee which can notify the original requestor without passing back through a delegator stack entry. The delegator need not receive any notification of the action of the delegatee - no call-return mechanism directly associated with the delegator. Perhaps alternative models of delegation do permit the delegator to behave as call-return processes. Richard Riehle
From: Thomas Kowalski on 7 Aug 2006 06:17
> >Therefore I am trying now to grasp as much of the "real" OO as possible > >with the goal to make my code more easy to understand. > > Ok start with cutting all technical things and talk talk talk about > your domain of application. Sorry ( I not 100% sure but this sentence seemed a little bit ironic, am I right? ;) ) > >Well, the software I am currently working on is settled in computer > >graphics. It's a high performance calculation software. Therefore some > >concepts of business OOA/D are difficult to apply for me. > > Please elaborate. The more astonishing oo applications even in the > start time of ooa/d where in this sector so it might be more easy to > find good domain references then you think. I maybe used the wrong words. After reading some books about OOA/D it's (still) difficult for me to actually apply it to my problem domain. One point of confusion was the following example: The software is working on objects consisting of slices (through the object) which consist of contours (closed polygons that represent the surface of the object). At some time these contours need to be divided / splittet in smaller contours. This is done using a graph structure. At first I implemented the methode split as a methode of the class contour and providing the graph as a parameter (split also might be a methode of the graph getting the contour as parameter). I guess the better idea would be to introduce a class ContourSplitter that does the job by getting a contour and a graph. Sorry for the (unneccessary?) details, but its the only way I guess to avoid misunderstandings. > >Basicly I am working on the assumption that an object encapsulates the > >methodes to manipulate itself, with might be not really right on second > >thought. > > In my experience Its always right. Sorry to say it that brutal but > believe me the tension that it brings helps you in the right way most > often See the example before. The contour needs to be divided, therefore at first glance it might appear right to add the methode split to this class. But that blows the classes code far too much. First attempt to reduce the codelength of the classes contour was to subclass it, resulting in a class like DividableContour. On second thought it might be advisible to rather introduce a new class like ContourSplitter that makes the "dirty work". > Define as many strong independent objects as you can BEFORE going into > scenario's or technical implemenation detail( which often is a like). That would be the contour and the graph in my case. > Dont bother about relations between objects at all at first. You will > see then that some rather obvious relations for behaviors arise. I totally agree. But there are a lot of border cases for unexperienced developers like me. Therefore I would like to know more about metrics, pitfalls, usage stories that might help to make the "right" decision (I guess there is no right but only a well working decision). > That kind of relations at the behavioral level can be considered ok as long > as they dont compromise the firm object identity that you established > upfront... But what to do if they do actually compromise the firm object identity, or at least seem to at first? Thanks again for taking the time to help me, Thomas Kowalski |