Abstract Classes vs Interfaces

[Guest]

Hi ,

Please help me by advising an real life scenario where Abstract Classes
should be used over Interfaces or vice versa . Whats the basic difference
between Abstract Class and interface other then instantiation ?

Many Thanks

Vishal Gandhi

 

[Patrice]

See :
http://msdn.microsoft.com/library/d...html/vbconAbstractClassesVersusInterfaces.asp

As an exemple for this exceprt :

"Abstract classes should be used primarily for objects that are closely
related, whereas interfaces are best suited for providing common
functionality to unrelated classes. "

see the Stream class (that is abstract, all streams having the same
behavior) and the IEnumerable interface (that is implemented by classes
having nothing else in common).

Patrice

 

[Helge Jensen]

"Abstract classes should be used primarily for objects that are closely
related, whereas interfaces are best suited for providing common
functionality to unrelated classes. "

Abstract classes should (in my opinion) only be used as
"implementation-helpers" skeletons of implementations which are just
missing some important parts.

Interfaces should be used to expose behavioural traits.

To use an abstract class to expose behavioural traits restricts the
implementations of that interface.

You can argue, that using an abstract class reduces the amount of
classes defined, but you save at-most 1 interface-declaration.

see the Stream class (that is abstract, all streams having the same
behavior) and the IEnumerable interface (that is implemented by classes
having nothing else in common).

I don't think Stream is a good example. A stream is a concept, an
idea... and not related to some specific way of implementation.

I would much have preferred Stream as an interface. and:

- a helper-class: ImpotentStream that would return false on all "CanX"
and throw on all other methods, allowing you to easily override just the
bits you use.
- an abstract helper-class: BlockingStream that required you to
implement CanRead, CanWrite, Read, Write, Flush & Close
- another abstract helper-class: NonBlockingStream that required you
to implement CanRead, CanWrite, BeginRead, BeginWrite & GetWaitHandle
- Adapters, implementing blocking IO in terms of non-blocking and the
inverse.

This increases the number of classes, but vastly decreses the complexity
of a working Stream-implementation.

The whole Stream "interface" smells bad, it smells like a .NET wrapper
for whatever C code was in win32.

It's basically a union of handy operations on "things". What is
"SetLength" doing on a stream? Why is CreateWaitHandle not just
"WaitHandle { get; }" and *why* is it protected. Why are there
operations to read/write single bytes.

 

[Vishnu-Chivukula]

Hi Vishal,

"The basic difference between an Abstract class and an interface is that
Abstract class allows Concrete method(methods that have implementation) but
interface doesn't. The second difference is in terms of inheritance. A class
can inherit from only one class but can implement any number of interfaces.
One more difference is that interface doesn't allow variables/constants to
be declared but abstract class allows for declaration of variables and
constants.

You should consider using interfaces when your design is complete in itself.
i.e., no further methods need to be added later on to the interface as any
newly added method in interface need to be implemented in all the classes
that implement that interface. On the other hand if we need to add a new
method to an abstract class, we can provide default implementation of that
method in abstract class and there is no need for existing implementing
classes to be changed in that case"

Check these links for more info on when to use what...

http://www.dotnetspider.com/Question9463.aspx
http://www.dotnetspider.com/technology/kbpages/1041.aspx

HTH,
Need any help, do post a msg back..

Happy Coding

 

[Jeff Louie]

First lets agree that an interface is analoguos to a C++ _pure_ virtual
class
with no implementation. An abstract class implies that it cannot be
instantiated but is designed to be extended. So the question becomes
when
to write an abstract class with a partial implementation vs when to
write a
pure virtual class with no implementation. And you ask for an example.
The
answer is to use an abstract class with a partial implementation when
you
must:

Defer the Final Implementation to Another More Knowledgeable Class

The quest is to find a situation where a lot of complicated logic is
implemented but the final implementation must be deferred to a more
knowledgeable class. The classic example is a quick sort routine. You
know
the algorithm but you cannot write the final implementation without
knowing
the actual ordinal behaviour of the type to be sorted. So you can write
an
abstract class with a powerful partial implementation leaving the
abstract
Compare(obj, obj) method without an implementation. The user of your
abstract class simply supplies a concrete implementaton of the Compare
method reusing the power of you quick sort algorithm. An alternative is
to
write a Sort method that takes an IComparable object that defines the
Compare method.

The downside of interfaces is that they are difficult to update. so.

In summary, if you have a well defined contract that will be implemented
by
many classes use an interface. If the contract is evolving, consider
using a
base class. Use a base class if you need to include implementation
details
such as in our generic quick sort algorithm.

Regards,
Jeff

 

[Guest]

Vishnu ,

Many Thanks for explanation . This gives more clarity , also if you will be
able to provide some calrification on Aggregate class with an example it will
help.

Cheers
Vishal

 

[Guest]

Many Thanks Jeff

 

[Guest]

Thanks Vishal for raising this topic. Thanks to Vishnu-Chivukula and Jeff for
giving the nice explanation of Abstract Classes vs Interface.

 

[Jeff Louie]

Hi Vishal.. Sure. Looks like you are taking a class! These are good
questions
that make you think. So. Composition is containment by ownership (black
diamond UML). Aggregation is containment by reference (white diamond
UML). The classic example is a car class.

Inheritance represents an IS_A relationship from a generalization to a
specialization. Containment represents a HAS_A relationship between the
whole and a part. So a car IS_A motorized vehicle, but HAS_A radio. The
two
relationships can be expressed in code thusly:

class Radio
{
...
}
class Vehicle
{
...
}
class Car : Vehicle
{
Radio r= new Radio();
}

An instance of Car contains an instance of a Radio so that the lifetimes
of the
radio and car are intertwined. This is "containment by ownership" making
Car
an example of a composite class. 

Containment can also be accomplished using references to external
objects.
"Containment by reference" can be expressed in code thusly:

class Radio
{
...
}
class Vehicle
{
...
}
class Car : Vehicle
{
private Radio r;
public Car(Radio r) {
...
this.r= r;
}
}


You can then create an instance of Car like this:


class Class1
{
[STAThread]
static void Main(string[] args)
{
Radio r= new Radio();
Car c= new Car(r);
}
}

An example of containment by reference is a read only wrapper class.

Regards,
Jeff
This gives more clarity , also if you will be able to provide some
calrification
on Aggregate class with an example it will help.