Re: stereotype service (was: underlying politics)

[Michael Hoennig "(mi)" <mi sun com>]

Hi Mike,

> I understand the benefits of interface granularity from the component
> author's standpoint, although I think the interfaces I just waded
> through take it to an extreme.
>
> Isn't the point of this to make it easier for the client author?
> Forcing client authors to wade through such a fragmented picture of the
> component they are embedding seems counterproductive in my book.

less fragmentation would result in less reusability. You will hear plenty 
implementors complain about "this interface is almost what I want, but 
these three methods (out of a dozen) really do no make sense for my 
component". It's just the message I got in almost 15 years of software 
development (over 10 on StarOffice). Our paradigm is actually: one aspect 
per interface. 

Actually it's mostly a problem of good documentation. And I know, our 
documentation is far away from being good enough. We had the idea of 
dynamic documentation generation with a web server. You could select 
whether you want to see the method syntax for C++, Python or Java. You 
could select whether you want to see only direct members, or all 
inherited as well. ...

	Michael