Re: Abstract Base Classes vs Interfaces?
- From: david <david@xxxxxxxxxxxxxxxx>
- Date: Thu, 29 Sep 2005 20:15:29 -0700
On 2005-09-29, Bob Powell [MVP] <bob@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
> Despite the documentations views Abstract classes and Interfaces are
> completely dissimilar and have very specific roles in an OO system.
They really don't.
Sure, there are circumstances where one or the other is the obvious
choice, and in those circumstances they do have specific roles. The
most obvious is mixin functionality which pretty much has to be defined
as an interface in .Net. Or when you want to provide a base
implementation, an abstract class is the only choice.
But there's a lot of gray area in between those two, and a great many
situations where either would do just as well. And in those situations
choosing between the two can be tricky and subtle.
> An abstract class forces a specific chain of inheritance onto the classes
> that are derived from it. Effectively they say that if you want to play in
> my playground you MUST have this particular minimum concrete implementation.
> You MUST be a member of my family.
That's kind of a strange definition of "concrete implementation", since
of course a pure abstract class has no implementation at all. I don't
*think* you're suggesting that one should never have a "pure" abstract
class (i.e., a class where all methods are MustOverride), but I'm not
sure from your post.
> This is useful for example if you wish to
> be able to pass around references to an abstract type yet assume that the
> derived class, that you don't know or care about the actual type of, has
> implemented the missing functionality. The GDI+ Brush class is a classic
> example of this. You cannot instantiate a brush but you can instantiate a
> SolidBrush, LinearGradientBrush, PathGradientBrush or TextureBrush and store
> it in a Brush variable.
>
> Interfaces specifically enforce the method / property contract without
> enforcing the class derivation relationships. Effectively they say if you
> want to play in my playground I don't care who you are as long as you obey
> my rules. You can take any class and derive from it adding in an interface
> implementation. This is useful if you want to do something like enable
> third-party developers to adhere to rules in your application or system
> without necessarily providing them with a DLL or a concrete class from which
> to derive their own.
OK, that eluded me. How does an interface let you do this? You still
need to provide third-party developers with a DLL to reference,
otherwise how are they going to implement the interface?
> .A good example of this is the ICollection interface
> that enables you to create a class that conforms to a specific contract yet
> doesn't have to be derived from any particular base class.
Actually, I think ICollection is a good example of the ambiguity between
interfaces and abstract base classes. ICollection really cries out to
be an abstract base class with a built-in SyncRoot and a default
IsSynchronized implementation. But you can't do that in .Net because the
contract of ICollection is essentially a mixin pattern. So it has to
be an interface.
That's the kind of design trade-off one comes across all the time. I'm
not disagreeing with any of your definitions above, I'm just saying that
choosing between the two is often quite tricky.
.
- References:
- Abstract Base Classes vs Interfaces?
- From: Sean Kirkpatrick
- Abstract Base Classes vs Interfaces?
- Prev by Date: Re: Loading DataSets and App Size
- Next by Date: Re: Module Scope between instance of the same class
- Previous by thread: RE: Abstract Base Classes vs Interfaces?
- Next by thread: FileSystemWatcher Question
- Index(es):
Relevant Pages
|
Loading
