Re: Derive concrete type from generic type.

I argue that the inheritance ideals (implementation and interface) are both
very useful but both can be harmful when not fully understood; just like
everything else in life.
I've read the article and I agree (and have always agreed) that base classes
can be fragile, but they do not have to be when the reason for the usage is
understood; it depends upon your design and intentions for the class itself.
Interface inheritance for the express purpose of replacing implementation
inheritance is egregious at best.  There is a reason for implementation
inheritance and that is to promote code reuse; to allow a common set of code
that applys to a variety of classes.  His example of the stack is contrived
to make the point.  When dealing with BCLs it's important to understand the
reason behind the BCL first then decide on the correct implementation; if
the base class is defective then the derived classes will also be defective;
you don't solve that by writing the stack code over and over and over for
every "derived" class you wish to create.

If I'm going to create business objects, interface inheritance is generally
not a good practice.  It means I must write the same code in every class.
For some simple boolean or string property this becomes a terrible burden
and can greatly increase the cost of development; I really hate copy and
paste inheritance; you're just asking for problems later on when your code
doesn't work and you've got 50 methods across 50 classes that all have to be
changed.  You can overcome this limitation by creating a "helper" class and
implementing the interface on the helper class as well and merely creating
instances of that class within the 50 other classes - but lets be reasonable
here - that's really just what implementation inheritance is for.
Inheritance is not evil but it can be if not used correctly.
It's not evil to inherit from List<T> to create a non-generic version of the
class - depending upon your purpose.

On Jan 22, 2008 5:57 AM, Daniel Petersson <[email protected]>
wrote:

> Frans is essentially right BUT... =)
>
> Some of us argue that inheriting classes such as List<T> to create new
> types is a bad thing.
> This discussion is more common in the JAVA community. Prior to completing
> your impl. I recomend that you read  this java article about inheritence VS
> interface implementation.
>
> http://www.javaworld.com/javaworld/jw-08-2003/jw-0801-toolbox.html
>
> Regards,
> Daniel
>
> ps the article is old and doesn't use generics but the problem I still the
> same ds
>
>
> ________________________________________
> From: Discussion of development on the .NET platform using any managed
>          language [[email protected]] On Behalf Of Frans
> Bouma [[email protected]]
> Sent: Tuesday, January 22, 2008 12:38 PM
> To: [email protected]
> Subject: Re: [DOTNET-CLR] Derive concrete type from generic type.
>
>  > Say I wanted a collection of Field objects, but with some extra
> > functionality, say constraints on how fields can be added.  I decided
> > List<Field> is a good fit for most requirements, but want to derive a
> > MyFieldList.  To the best of my limited generics knowledge, I have to
> derive
> > a MyFieldList<T> anyway, but all my refinements in the child class only
> > refer to type Field, so the generic parameter is basically redundant.
>  Is
> > there any way around this?
>
> public class MyFieldList : List<Field>
> {
>
> ...
> }
>
>                FB
>
> ===================================
> This list is hosted by DevelopMentor?  http://www.develop.com
>
> View archives and manage your subscription(s) at
> http://discuss.develop.com
>
> ===================================
> This list is hosted by DevelopMentor(R)  http://www.develop.com
>
> View archives and manage your subscription(s) at
> http://discuss.develop.com
>

===================================
This list is hosted by DevelopMentor®  http://www.develop.com

View archives and manage your subscription(s) at http://discuss.develop.com