Hi Éric, > Well, what's the point of reusability if you can not simply assemble (or > derive) classes by an operation as simple as a cut or past. Same goes even > for old procedural programming. If you have to study the code of all the > stuff you assemble / derive / call, you can't really all that reusability.
Not sure we're talking about the same cut'n'paste here :) What I mean is large chunks of codes which do exactly the same thing (including having the same bugs) in different locations. Code which could be outsourced in some common routine/class/whatever. That's not about reusability, but about lazyness of the developer :) And no, surely you should not be required to study the code, but only the interface. It's irrelevant here whether this interface is some global method, some base class with clear hooks, or some abstract interface class. In any case, what makes this interface (re)usable is a clear documentation what it does, what it doesn't do, what's expected from the client, what#s promised to the client, and so on. > To some extent, you have to be able to see software components as "black > boxes" known only through their external declarations and their documentation > (and yes, that does not depend on on your programming paradigms). Ah, well, yes, that's what I wanted to say :) > The specific problem with composition (and multiple inheritance) is that it's > very easy to assemble class A and class B that both derive from a common > class C, therefore leading to duplication at least of variables. Or that > class A and class B have both methods for more or less the same idea. Yes, that's something I in fact don't like about composition :) Probably, that's the cut'n'paste you meant: If I have a class Foo providing some functionality, and which is intended to be "composed into" classes which also need to provide this functionality, then those other classes all duplicate code: At least, the forwarding to the Foo instance they hold internally ... >>>Sometimes when I look of some code in OOo I get the impression "oh, 90% >>>of this class might not be used. >> >>This might/not be true, but again, what does this have to do with >>"composition vs. inheritance"? :) > > Because you usually reuse things way too strong for your needs. Which I don't cosider bad. As long as there are other clients using the strength, and it doesn't cost extra in the implementation, that's okay to me ... Ciao Frank -- - Frank Schönheit, Software Engineer [EMAIL PROTECTED] - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Database http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
