Hi Éric,
> Well.. With a lot of C++ background ;-).
(my background, and still my major playground, is C++, too. Some years
ago, having written a lot of C++ already, you would have heard me saying
"Java simply sucks" :) - so this is certainly not the difference here.)
> And too be honest, with also a strong
> bias towards "simpler" things. Multiple inheritance - or composition - leads
> naturally to more complicated software than simple inheritance.
Hmm. Not sure. Really not sure. ("trying out" would probably have been
better that "playing around with" in my wording: I'm still testing
whether I like it.)
What I like is that you more often break you problem in smaller pieces,
giving certain small components an explicit, well-defined
responsibility, instead of having a large "I can do everything,
including cooking coffee" component. I'm not sure this really makes the
software more complex ...
>>As said, I recently played around with the concept of composition (read:
>>I extensively used it in recent implementations, if possible), and my
>>impression is: it's more difficult to do. That is simply because you're
>>now more forced to think about your design befoerhand,
>
> ... which is somehow broken:
> 1) Your needs change over the time, naturally
I could say a good design is easy to extend :)
> 2) "You are not going to need it" (YNGNI) problem : you should not need to
> think about you might need someday
I disagree, to a certain extent. IMO, you should think what you might
need in the future - this is independent from "composition or
inheritance". It's just than in one case, extensions are easier, but
also more probably to lead to clumsy code over time (and seeing some
code in OOo which grew over years, I mean what I say!).
> 3) reusability also means writing code that could be reused in contexts that
> you did not figure out
I think it's unlikely that you can reuse code *unchanged* in a context
which you didn't anticipate before - again no matter which architecture
you chose. You probably need changes the one or the other way, it's
again only a question how good your code is prepared for changes, and
how good it preservers "quality" (which is fuzzy, I know) when changed.
> I feel there's also a danger to bloat your software by composing too much
> functionality, and perharps even leading to duplication of functionality.
At least the latter (I'm not sure about the former) is, IMO, a problem
of lazyness. If you duplicated code, you did something wrong. Looking at
existing code, this, once more, is definately no problem of composition.
I'm often ... astonished how easily people seem to just
copy-paste-modify code, instead of putting a common base in there.
> 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"? :)
However, I'd agree that especially when designing and implementing UNO
components, then often, you care for, and implement, functionality which
is not actually needed for the concrete problem you solve. I don't
consider this a bad thing - finally, UNO is a component model, intended
to be the base for not only the OOo suite, but also for, say,
"application development based on OOo".
>>From this sentence I suppose you intended to cc' this to [EMAIL PROTECTED]
> Didn't I do so ?
Not in the first message.
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]
