delegation vs. inheritance
in [OOP]
|
From: Thomas Kowalski on 3 Aug 2006 06:03 Hi everybody, 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. Is such a concept basicly a "good" idea? If yes, should it be realized using delegation or inheritance? I have already read about the LSP, but are there any other guidelines then to use inheritance and then delegation? Last one is really tedious to implement and don't necessarily reduce complexity (since the methode stubs are still part of the code). On the other hand inheritance is a pretty strong relationship. Another occurance that let me thing about that problem is corba, there two different approaches are used to create proxy objects (tie = delegation and interfaces = inheritance). Is there any reason to use ties, beside the fact that java doens't support multiple inheritance? Thanks in advance, Thomas Kowalski
From: Dmitry A. Kazakov on 3 Aug 2006 06:25 On 3 Aug 2006 03:03:28 -0700, Thomas Kowalski wrote: > Another occurance that let me thing about that problem is corba, there > two different approaches are used to create proxy objects (tie = > delegation and interfaces = inheritance). Is there any reason to use > ties, beside the fact that java doens't support multiple inheritance? I think the reason is always same, in some general sense, delegation = inheritance for the poor. A middleware might use a tie when there is no better way to express inheritance in a distributed case. For example, when a request has to be queued and requeued from object to object, just because objects are located on different hosts. But is it single distributed object, several separate objects of related types, or all of different types? -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de
From: Rick Elbers on 3 Aug 2006 08:42 Thomas, Might I suggest a little ooa/d before you go into technical refactoring like this ? 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). Then the implementation point. If you talk like " >My idea was to simplify huge classes by dividing them in a base class >and additional class that provide other attributes / aspects / >functionality. " You might miss the whole point about inheritance/delegation. 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. Op 3 Aug 2006 03:03:28 -0700 schreef "Thomas Kowalski" <th-ko(a)gmx.de>: >Hi everybody, > >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. > Mixins is a nice implementation certainly when you have clients who only receive one of the mixins instead of the whole monster. >Is such a concept basicly a "good" idea? If yes, should it be realized >using delegation or inheritance? I have already read about the LSP, but >are there any other guidelines then to use inheritance and then >delegation? Last one is really tedious to implement and don't >necessarily reduce complexity (since the methode stubs are still part >of the code). On the other hand inheritance is a pretty strong >relationship. > If you have a design in which you need runtime dynamics often delegation is much better. You can implement new strategies, states or engines and put them in your scenario at runtime. Such a thing is impossible with inheritance since it is runtime static. >Another occurance that let me thing about that problem is corba, there >two different approaches are used to create proxy objects (tie = >delegation and interfaces = inheritance). Is there any reason to use >ties, beside the fact that java doens't support multiple inheritance? > >Thanks in advance, >Thomas Kowalski
From: Sasa on 3 Aug 2006 09:40 "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. > 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. > > Is such a concept basicly a "good" idea? If yes, should it be realized > using delegation or inheritance? I have already read about the LSP, but > are there any other guidelines then to use inheritance and then > delegation? Last one is really tedious to implement and don't > necessarily reduce complexity (since the methode stubs are still part > of the code). On the other hand inheritance is a pretty strong > relationship. As a person who often abused inheritance (simply because it is easy to do so), I advice caution with inheritance. My personal guideline to inheritance is something like following: a) Is there a code which works with base class interface? b) Can that code work with my derived class? c) Can my derived class work with base class methods? I.e. if I invoke base class method, will something unexpected happen because my derived class doesn't count with it. d) Did I override anything in derived class? If answer to any of those questions is no, then I think twice whether inheritance is the way to go. The inheritance seems very appealing at the first glance, because in one line of code you get everything - the interface, and the entire implementation, and in addition, you have more access to class members. However, this has its darks side - the clients of my (derived) class are completely unshielded from the specifics of the base class. Nowadays, I am more fan of the delegation approach, even if it is somewhat tedious. I regard inheritance vs. delegation as having two different purposes: in inheritance, we reuse the interface and provide our own implementation, in delegation we provide our own interface and reuse implementation. Sasa
From: Thomas Kowalski on 3 Aug 2006 10:25
Hi Sasa, thanks for your reply! Maybe you can eleborate the answers a little bit more? > a) Is there a code which works with base class interface? If the dividing in base and derived class simplifies the understanding of the concept the class represents, when why not using it? > b) Can that code work with my derived class? This is basicly the LSP, isn't it? > c) Can my derived class work with base class methods? I.e. if I invoke base > class method, will something unexpected happen because my derived class > doesn't count with it. Seems to be something like LSP, too. > d) Did I override anything in derived class? Why this is important? If you just add functionallity, doesn't it justify the use of inheritence? > ...you have more access to class members. > However, this has its darks side - the clients of my (derived) class are > completely unshielded from the specifics of the base class. Not if you declare the members private instead of protected. Which might be most usefull if just few or none members of the class is overridden. > Nowadays, I am more fan of the delegation approach, even if it is somewhat > tedious. What caused the shift in attitude? > I regard inheritance vs. delegation as having two different purposes: in > inheritance, we reuse the interface and provide our own implementation, in > delegation we provide our own interface and reuse implementation. I really like this explaination! That really seems to bring it to the point :) Thanks, Thomas Kowalski |