Abstract class or interface?

[Brett]

I'm still trying to figure out concrete reasons to use one over the other.
I understand the abstract class can have implementation in its methods and
derived classes can only inherit one abstract class. The interface has
implied abstract methods/properties and derived classes can inherit multiple
interfaces. The interface properties/methods have no implementation.

Besides definitions of the two, what are some conceptual reasons to use one
over the other? Perhaps examples of this project uses an abstract classes
vs. this one uses an interface...for these reasons.

I have one project that uses an interface. I chose the interface over an
abstract class because the derived classes all do the same thing, they just
go about doing it in slightly different ways. Their results are different
but conceptually what they do is the same thing. I don't ever see the need
for adding more methods or properties to the interface. If there is every
such a need, I can encapsulate this variability into one of the derived
classes, since it will be "one" that has such a need rather than all. That
make sense?

Thanks,
Brett

 

[Dave]

They can be employed in the use of design patterns that may better explain their purpose than I can in a single post:

http://www.dofactory.com/Patterns/Patterns.aspx

 

[Joshua Flanagan]

I try to make the decision based on the relationship of the derived
class to the base class.

If the derived class "is a" type of the base class, I'd lean towards an
abstract class. Ex: A FileStream is a type of Stream.

If the derived class "can act like" (or, has the behavior of) the type
of the base class, I'd lean towards an interface. Ex: A String has the
behavior of an ICloneable object. But you probably wouldn't consider
the fact that it implements ICloneable as a defining characteristic of
what the String class is all about; it is just one of the String class's
behaviors.

Note my unwillingness to make definite statements. That's on purpose,
as I consider these just guidelines, not strict rules.


Joshua Flanagan
http://flimflan.com/blog

 

[Jeff Louie]

The simplest way to look at this is to understand that an interface is
functionally equivalent to a pure virtual abstract class. So an
interface is a
special case of an abstract class, one with no implementation. Given
that C#
only supports single inheritance of implementation and multiple
inheritance
of interfaces, then the question collapses to When should I use an
abstract
class with no implementation vs an interface? One answer is to use an
abstract class with no implementation when the interface is subject to
significant change. This allows you to add new methods with default
implementations to the base class without breaking existing clients of
the
base class. Another answer is to use an interface when classes may need
to
inherit from more than one interface. Another answer is to provide both
an
interface and an abstract class with default implementations of the
interface.

Regards,
Jeff

 

[Jon Shemitz]

what are some conceptual reasons to use one over the other?

One way to look at it is "breadth" vs "depth".

You don't know much about the objects that implement your interface,
and this gives you a lot of implementation flexibility. With an
interface, you don't care what else the object can do, so long as it
implements your interface. To use a hackneyed example, imagine an

interface IText { string Text { get ; set ; } }

- you don't care if an IText reference is a desktop Form or other
Control, a web control, or a custom class. An IText[] array could
freely mix all three - every IText has a Text property, regardless of
how it's implemented or what else the object can do.

Conversely, with an abstract class, you can know things about your
objects that you can't know about an interface. (For example, you
can't mark an interface method as [Obsolete], nor is there any way to
insist that all interface implementations be [Serializable].) You can
have constructors, protected members, fields, attributes. Descendants'
implementation of various methods can rely on non-public features of
the base class.

An interface is appropriate when you don't care about anything besides
what can be expressed in an interface. Or when you need to treat a
wide variety of objects in a consistent manner. An abstract base class
is appropriate when you have a tightly coupled family of objects, that
need (or can benefit from) access to protected fields and helper
methods.

[At the risk of confusing the issue, a set of classes that implement
an interface might all descend from a common base class (besides
System.Object, that is) that provides some standard implementations of
all or part of the interface.]

As a rule of thumb, use an interface unless there's a really obvious
reason to use an abstract base class. Information Hiding Is Your
Friend.

 

[Bob Powell [MVP]]

Abstract classes require and imply inheritance whereas interfaces do not.

An abstract class would be used wherever it was important to enforce some
aspect of the implementation an interface is used where only the agreement
between how an object presents itself and how other objects consume it is
important.

An abstract class ensures that derived objects are part of the same
inheritance tree. Interfaces enable totally unrelated objects to present the
same face to the outside world.

--
Bob Powell [MVP]
Visual C#, System.Drawing

Find great Windows Forms articles in Windows Forms Tips and Tricks
http://www.bobpowell.net/tipstricks.htm

Answer those GDI+ questions with the GDI+ FAQ
http://www.bobpowell.net/faqmain.htm

All new articles provide code in C# and VB.NET.
Subscribe to the RSS feeds provided and never miss a new article.

 

[James Curran]

Abstract classes require and imply inheritance whereas interfaces do not.

Huh?

Abstract classes tecnically do not "require" inheritance. You can
define as many as you like, without ever deriving a class from any of them.
You cannot instanitate an object of that class, or otherwise use it, but
they will happily live in your assembly.

Yes, that's silly, but the same can be said for interfaces. Interfaces
"require and imply" implementation in precisely the same way as abstract
classes do for inheritance.

--
--
Truth,
James Curran
[erstwhile VC++ MVP]

Home: www.noveltheory.com Work: www.njtheater.com
Blog: www.honestillusion.com Day Job: www.partsearch.com

 

[Jeff Louie]

Bob... Hopefully I can convince you that this is not really true. I am
going to argue yet again that an interface is funtionally equivalent to
a pure virtual abstract class in C++. By design, C# does not support
multiple inheritance of implementation like C++ does. Instead, C#
supports multiple inheritance of pure virtual classes (interfaces) and
single inheritance of an implemention hierarchy. The concept of an
interface is just syntax that enforces this restriction. Many C++
frameworks are based on mulitiple inheritance of pure virtual abstract
classes and are functionally equivalent to the .NET framework's use of
multiple inheritance of interface.

Regards,
Jeff
Abstract classes require and imply inheritance whereas interfaces do
not.

 

[ozbear]

I'm still trying to figure out concrete reasons to use one over the other.
I understand the abstract class can have implementation in its methods and
derived classes can only inherit one abstract class. The interface has
implied abstract methods/properties and derived classes can inherit multiple
interfaces. The interface properties/methods have no implementation.

Besides definitions of the two, what are some conceptual reasons to use one
over the other? Perhaps examples of this project uses an abstract classes
vs. this one uses an interface...for these reasons.

I have one project that uses an interface. I chose the interface over an
abstract class because the derived classes all do the same thing, they just
go about doing it in slightly different ways. Their results are different
but conceptually what they do is the same thing. I don't ever see the need
for adding more methods or properties to the interface. If there is every
such a need, I can encapsulate this variability into one of the derived
classes, since it will be "one" that has such a need rather than all. That
make sense?

Thanks,
Brett

I have a 3-D package that under user control needs to be able to move
and rotate "things" along all three X, Y, and Z coordinate axis.

The "things" could be sinple points (Vertex class), lines (Line
class), planar faces (Faces class), or solid things (Solids class).

All these things are defined as supporting the I3D interface whch
means they must implement methods such as Rotate(x angle, y angle,
z angle), Translate(some axis), Scale(some percentage), and so forth.

Rotating a Vertex is different than a Line, but the interface doesn't
know nor care what the differences are. Furthermore, I can place all
the different things in an ArrayList by their interface and then run
a simple...

foreach (I3D i3dobj in arraylist)
i3dobj.Rotate(xangle,yangle,zangle);

to rotate all the objects in the scene.

In this example it would be possible to define an abstract class
called, say, Ab3D, and have Vertex, Line, Face, etc., derive from
Ab3D and override the Rotate, Translate, etc. methods in each.
THis implies some closer coupling between these classes than I
would like, furthermore...

What if I want to include rotated text or something else where
the bulk of the work is already defined in an existing class which
does not derive from Ab3D? If I don't have control of that existing
class' definition, or if it itself is a derived class I cannot make it
derive from Ab3D to override those methods.

With interfaces however, I can derive a new class from that already
existing one, state that it supports the I3D interface, and then
write the supporting Rotate, Translate, etc., methods for it. Then I
can include it in the arraylist above and perform the 3D actions on
it with no changes to manipulation code. I do not have to change
the interface to make new things 3D manipulatable.

Oz

 

[Brett]

I have a 3-D package that under user control needs to be able to move
and rotate "things" along all three X, Y, and Z coordinate axis.

The "things" could be sinple points (Vertex class), lines (Line
class), planar faces (Faces class), or solid things (Solids class).

All these things are defined as supporting the I3D interface whch
means they must implement methods such as Rotate(x angle, y angle,
z angle), Translate(some axis), Scale(some percentage), and so forth.

Rotating a Vertex is different than a Line, but the interface doesn't
know nor care what the differences are. Furthermore, I can place all
the different things in an ArrayList by their interface and then run
a simple...

foreach (I3D i3dobj in arraylist)
i3dobj.Rotate(xangle,yangle,zangle);

to rotate all the objects in the scene.

In this example it would be possible to define an abstract class
called, say, Ab3D, and have Vertex, Line, Face, etc., derive from
Ab3D and override the Rotate, Translate, etc. methods in each.
THis implies some closer coupling between these classes than I
would like, furthermore...

What if I want to include rotated text or something else where
the bulk of the work is already defined in an existing class which
does not derive from Ab3D? If I don't have control of that existing
class' definition, or if it itself is a derived class I cannot make it
derive from Ab3D to override those methods.

With interfaces however, I can derive a new class from that already
existing one, state that it supports the I3D interface, and then
write the supporting Rotate, Translate, etc., methods for it. Then I
can include it in the arraylist above and perform the 3D actions on
it with no changes to manipulation code. I do not have to change
the interface to make new things 3D manipulatable.

Oz
--
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

Thanks. Great example. Say your interface has three methods - X, Y, Z.
You want to add a forth - Time or T. What now? This is completely
unexpected. I know you could allow your implementation to inherit from
another interface, perhaps called ITime. What is best?

Brett

 

[Jon Shemitz]

Thanks. Great example. Say your interface has three methods - X, Y, Z.

You want to add a forth - Time or T. What now? This is completely
unexpected. I know you could allow your implementation to inherit from
another interface, perhaps called ITime. What is best?

Adding the new method to the existing interface ensures that you have
to add the new method to all the classes that support the interface.
This is good, unless you have "published" the interface, and third
parties have implemented it.

Creating a new interface - possibly inheriting from the old one -
doesn't break existing code. Conversely, it doesn't guarantee that all
classes suppport the new member, and it means that you have to do
tests like "does this class also support the new interface".