Fwd: Q: Expanding an Inherited Interface?

[Fabio Augusto Mazzarino]

from comp.object

 i know many of you read comp.object, but i thought some of you would like
to see this...

mazza.br

Pavel A. Perikov <pavel at tversu.ru> escreveu nas notícias de
mensagem:391BF134.DD7E19B4 at tversu.ru...
> First I'll try to answer to the "PS" in your letter
>
> > (PS:  Can anyone tell me why this question was rejected on
> > comp.object.moderated??)
>
> I suggest, that the reason for the question been rejected is because the
answer
> can be found in some FAQ. And the answer is somethin like "it depends". I
> personaly didn't read such FAQ but here's my very own opinion compiled
from
> reading and own experience.
>
> There're many ways you can use inheritance. Someone told me - more then a
dozen.
>
> Inheritance often is treated as a mean to support particular design
principle
>
> First we can speak about type inheritance. This is where Liskov's
Principle come
> into concern. Classes in common programming languages (esp. C++) are more
then
> just types. Java's interface inheritance  seems to be a good approximation
for
> type inheritance. Adding public methods to derived interface doesn't
violate the
> possibility of using derived interfaces in place of base.
>
> Second, you can share code via inheritance. This has generealy nothing to
do
> with type inheritance. You just split responsibilities into the classes in
the
> inheritance hierarhy.
>
> You can combine interface with implementation via inheritance. C++:
> class Interface {/* all public pure virtual functions */};
> class Implementation {/*virtual implementation of the functions from
interface
> */};
> class My: virtual public Interface, private Implementation {...}
>
> You can just provide implementation for the interface using "public
virtual"
> inheritance of the interface class.
>
> There're many others.
>
> My rule for using inheritance: use it in analysis, where gen-spec relation
> exists between concepts in problem domain. Use it in design/implementation
> according to your coding style and requirements of the enviroment (you can
have
> libraries imposing their particular way). And please always consider what
you're
> trying to express with the inheritance. It's quite easy to abuse
inheritance.
>
> Yours, Pavel.
> P.S. Please ignore my poor English ;)
>
> "" wrote:
>
> > I have often heard that inheritance hierarchies should not violate the
> > Liskov Substitution Principle (derived classes must be usable through
the
> > base class interface without the client having to know the
> > difference).  But does this also imply that you should not add public
> > methdos to the derived class interface?  Or can you do this if you are
using
> > inheritance as a method of code sharing; which raises a second
question...
> > should you use inheritance as a method of code sharing, or should
> > aggregation always be used?
> >
> > Thanks,
> > - Peter
> >
> > (PS:  Can anyone tell me why this question was rejected on
> > comp.object.moderated??)
>