Interface vs. Abstract Class

[Bradley]

I'm trying to determine if there's a general rule for when an Interface
should used vs. an Abstract Class. Is there any design advantage to using
one or the other?

Brad

[Tom Porterfield]

Re: Interface vs. Abstract Class

Bradley wrote:[color=blue]
> I'm trying to determine if there's a general rule for when an Interface
> should used vs. an Abstract Class. Is there any design advantage to using
> one or the other?[/color]

Seems a good place to start is by looking at the difference between the
two. For starters someone implementing an interface can implement
multiple interfaces and can also have a base class. With an abstract
base, that is the only base class they can have, although they could
implement other interfaces. What this means is that two classes that
are completely unrelated in any other way could both implement your
interface. With an abstract class, anyone inheriting from your abstract
class would be more closely related in that they would all have a same
base type (your abstract class) in their inheritance hierarchy.

With an abstract class you can, if you want or need, provide some
implementation in the abstract class. An interface can provide no
implementation.
--
Tom Porterfield

[Kevin Spencer]

Re: Interface vs. Abstract Class

Well, if the implementations share a lot of code, you're probably looking at
an abstract class. On the other hand, if you just want the programming
interface to conform to a certain set of sigunatures, and there is little or
no possibility that the implementations will share code, you're probably
looking at an Interface.

That's it in a nutshell. Broadly speaking.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
Ambiguity has a certain quality to it.

"Bradley" <brad.markisohn @roche.com> wrote in message
news:ODmvBWN1FH A.1040@TK2MSFTN GP14.phx.gbl...[color=blue]
> I'm trying to determine if there's a general rule for when an Interface
> should used vs. an Abstract Class. Is there any design advantage to using
> one or the other?
>
> Brad
>
>[/color]

[Bradley]

Re: Interface vs. Abstract Class

Thanks for the responses. It sounds like unless you need to inherit
implementation code, there's very little difference.

Brad

"Kevin Spencer" <kevin@DIESPAMM ERSDIEtakempis. com> wrote in message
news:eK0azfN1FH A.3300@TK2MSFTN GP15.phx.gbl...[color=blue]
> Well, if the implementations share a lot of code, you're probably looking[/color]
at[color=blue]
> an abstract class. On the other hand, if you just want the programming
> interface to conform to a certain set of sigunatures, and there is little[/color]
or[color=blue]
> no possibility that the implementations will share code, you're probably
> looking at an Interface.
>
> That's it in a nutshell. Broadly speaking.
>
> --
> HTH,
>
> Kevin Spencer
> Microsoft MVP
> .Net Developer
> Ambiguity has a certain quality to it.
>
> "Bradley" <brad.markisohn @roche.com> wrote in message
> news:ODmvBWN1FH A.1040@TK2MSFTN GP14.phx.gbl...[color=green]
> > I'm trying to determine if there's a general rule for when an Interface
> > should used vs. an Abstract Class. Is there any design advantage to[/color][/color]
using[color=blue][color=green]
> > one or the other?
> >
> > Brad
> >
> >[/color]
>
>[/color]

[Derrick]

Re: Interface vs. Abstract Class

Ditto. But when I do it, I tend to create both (i.e., the abstract/base
class implements an interface). I've found this useful to have when all of
a sudden I find the abstract class doesn't cut it anymore, and have to go to
the interface. I figured since it's done a lot in the framework, I may as
well do it too!!

Derrick


"Kevin Spencer" <kevin@DIESPAMM ERSDIEtakempis. com> wrote in message
news:eK0azfN1FH A.3300@TK2MSFTN GP15.phx.gbl...[color=blue]
> Well, if the implementations share a lot of code, you're probably looking
> at an abstract class. On the other hand, if you just want the programming
> interface to conform to a certain set of sigunatures, and there is little
> or no possibility that the implementations will share code, you're
> probably looking at an Interface.
>
> That's it in a nutshell. Broadly speaking.
>
> --
> HTH,
>
> Kevin Spencer
> Microsoft MVP
> .Net Developer
> Ambiguity has a certain quality to it.
>
> "Bradley" <brad.markisohn @roche.com> wrote in message
> news:ODmvBWN1FH A.1040@TK2MSFTN GP14.phx.gbl...[color=green]
>> I'm trying to determine if there's a general rule for when an Interface
>> should used vs. an Abstract Class. Is there any design advantage to
>> using
>> one or the other?
>>
>> Brad
>>
>>[/color]
>
>[/color]

[Alex Li]

Re: Interface vs. Abstract Class

Brad,

This is how I would start: Initially if I am not sure which one to
use, then I would use an Interface. Now, once you have a few
implementation classes for that interface, you may realize that there
are some methods that have code that are always the same between the
classes. You can extract out those methods; one way is to extract them
out to a common parent class. In this case, the new implementation
class would need to inherit from the parent class and implement the
interface. If the parent class and the interface are always used
together, then you may want to use an abstract class instead to group
them together, so you won't be accidentally using just the interface
but not the parent class.

HTH,
Alex

[Jeff Louie]

Re: Interface vs. Abstract Class

Bradley... After you code for a while you will discover the sudden need
to add a method to an interface. This is a bad place to be. Changing the
interface will break all clients. Soooooo. You need to refactor the
interface so that you can easily extend the framework. You need to be
sure about the interface. If you are not sure about the interface you
may want to start with an abstract class. If you add a method to the
abstract class, you can add a default implementation and not break any
clients.

Regards,
Jeff
Is there any design advantage to using
one or the other?


*** Sent via Developersdex http://www.developersdex.com ***

[Willy Denoyette [MVP]]

Re: Interface vs. Abstract Class


"Bradley" <brad.markisohn @roche.com> wrote in message
news:ODmvBWN1FH A.1040@TK2MSFTN GP14.phx.gbl...[color=blue]
> I'm trying to determine if there's a general rule for when an Interface
> should used vs. an Abstract Class. Is there any design advantage to using
> one or the other?
>
> Brad
>
>[/color]

Interfaces are most appropriate when defining contracts between types that
are invariant over time.
You also need to use interfaces when you want to provide polymorphic value
type hierarchies (value types cannot inherit from other types).
But in general you would prefer abstract types over interfaces as they
version much better and they are extensible.

Willy.

[Jon Skeet [C# MVP]]

Re: Interface vs. Abstract Class

Jeff Louie <jeff_louie@yah oo.com> wrote:[color=blue]
> Bradley... After you code for a while you will discover the sudden need
> to add a method to an interface. This is a bad place to be. Changing the
> interface will break all clients. Soooooo. You need to refactor the
> interface so that you can easily extend the framework. You need to be
> sure about the interface. If you are not sure about the interface you
> may want to start with an abstract class. If you add a method to the
> abstract class, you can add a default implementation and not break any
> clients.[/color]

On the other hand: use mock frameworks for unit testing is *much*
easier with interfaces.

I do take your point about breaking changes, but it's worth noting that
lots of people are in lots of different deployment situations. In many
cases, you know all the implementors of an interface, and can change
them all appropriately. In many other cases, you really can't do that -
so you have to end up creating another interface, etc. (Icky.)

--
Jon Skeet - <skeet@pobox.co m>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[Jeff Louie]

Re: Interface vs. Abstract Class

Jon... In fact, I relentlessly code to an interface in this situation.
If I need to add a method to the interface the compiler immediately
finds all of the invalid classes for me!!!!! Then I just update the
classes until the compiler stops complaining :).

Regards,
Jeff
In many cases, you know all the implementors of an interface, and can
change them all appropriately.

*** Sent via Developersdex http://www.developersdex.com ***

[Kevin Spencer]

Re: Interface vs. Abstract Class

As Uncle Chutney sez, "it's six of one of half of one of half of a dozen of
the other."

I don't believe it is possible from either angle to write code that doesn't
need rewriting at some point. At least I know that I'm not that good! ;-)

--

Kevin Spencer
Microsoft MVP
..Net Developer
Ambiguity has a certain quality to it.

"Jeff Louie" <anonymous@devd ex.com> wrote in message
news:OvKvwxP1FH A.3924@TK2MSFTN GP14.phx.gbl...[color=blue]
> Jon... In fact, I relentlessly code to an interface in this situation.
> If I need to add a method to the interface the compiler immediately
> finds all of the invalid classes for me!!!!! Then I just update the
> classes until the compiler stops complaining :).
>
> Regards,
> Jeff
> In many cases, you know all the implementors of an interface, and can
> change them all appropriately.
>
> *** Sent via Developersdex http://www.developersdex.com ***[/color]

[Bruce Wood]

Re: Interface vs. Abstract Class

When making this decision, I always go back to O-O basics. Let's say I
have a class Derived and I'm trying to decide whether to make it a
derived class of an abstract base class Base, or simply have it
implement interface Inter.

First, I ask myself whether Derived "is a" Base. That is, in the real
world, is Derived a special-case example of Base, or is that too odd a
concept? If I need the same functionality across classes that don't
have a strong enough relationship that I want to entrench that
relationship in my class hierarchy, then I go with the interface Inter.

For example, if Derived is an InHousePurchase Order, then I'd say that
it's certainly a special case of an abstract PurchaseOrder. Should
PurchaseOrder derive from another base class called Document? That's a
tougher decision: there are lots of other documents in my system that
have nothing in particular to do with purchase orders, other than that
they are also documents. I don't think that I would want to build up my
inheritance hierarchy by relating classes that are otherwise unrelated
in the real world... the relationship between, say, a purchase order
and a manufacturing drawing is just too tenuous for an important class
relationship like inheritance. I would go instead for an IDocument
interface.

That, to me, is really the crux of it: do these things have a
real-world "is-a" relationship, or not? In Java and C# I have only
single inheritance to work with, so having two classes participate in
that "is-a" relationship is a big deal in these languages. C++
programmers can be a bit more relaxed about the decision.

Yes, I too sometimes create abstract classes just to keep common code
in one place, but I usually do that only with strictly internal,
"housekeepi ng" classes, and then only in cases in which an interface is
clearly inadequate.

[David Levine]

Re: Interface vs. Abstract Class


"Jon Skeet [C# MVP]" <skeet@pobox.co m> wrote in message
news:MPG.1dc0ca 97518a549f98c96 2@msnews.micros oft.com...[color=blue]
> Jeff Louie <jeff_louie@yah oo.com> wrote:[color=green]
>> Bradley... After you code for a while you will discover the sudden need
>> to add a method to an interface. This is a bad place to be. Changing the
>> interface will break all clients. Soooooo. You need to refactor the
>> interface so that you can easily extend the framework. You need to be
>> sure about the interface. If you are not sure about the interface you
>> may want to start with an abstract class. If you add a method to the
>> abstract class, you can add a default implementation and not break any
>> clients.[/color]
>
> On the other hand: use mock frameworks for unit testing is *much*
> easier with interfaces.[/color]

How would it be easier? I don't see how it would be much different then
using an abstract base class?
[color=blue]
>
> I do take your point about breaking changes, but it's worth noting that
> lots of people are in lots of different deployment situations. In many
> cases, you know all the implementors of an interface, and can change
> them all appropriately. In many other cases, you really can't do that -
> so you have to end up creating another interface, etc. (Icky.)
>[/color]

The MSFT design guidelines (see Krzysztof Cwalina blog) suggest using
abstract base classes rather then interfaces. You get all the advantages of
an interface with fewer limitations. I tend to agree with these guidelines.
From an abstract :-) perspective, how does an interface differ from an
abtract base class with no implementation?

[Tom Porterfield]

Re: Interface vs. Abstract Class

David Levine wrote:[color=blue]
> The MSFT design guidelines (see Krzysztof Cwalina blog) suggest using
> abstract base classes rather then interfaces. You get all the advantages of
> an interface with fewer limitations. I tend to agree with these guidelines.
> From an abstract :-) perspective, how does an interface differ from an
> abtract base class with no implementation?[/color]

I think it comes down to your requirements and how much flexibility you
want to allow. With an abstract base class you certainly do *not* get
all the advantages of an interface. If you use an abstract base class
you are forcing everyone to use that as their base if they want to play
in your game. There are times when this would be desired. However that
means that a class with some other base class won't be able to
participate. If you were to instead use an interface then anyone could
implement your interface regardless of their inheritance chain. The
advantage to that is that two otherwise completely unrelated classes
could plug into your design as long as they implemented your interface.

I don't think anyone can make a blanket recommendation that either an
abstract base class or an interface is always the right answer. Rather
you must understand the strengths and weaknesses of each and make the
best decision based on your requirements.
--
Tom Porterfield

[Kevin Spencer]

Re: Interface vs. Abstract Class

I'm beginning to feel a bit like Gulliver.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
Ambiguity has a certain quality to it.

"Tom Porterfield" <tpporter@mvps. org> wrote in message
news:OgKqEjj1FH A.3336@TK2MSFTN GP12.phx.gbl...[color=blue]
> David Levine wrote:[color=green]
>> The MSFT design guidelines (see Krzysztof Cwalina blog) suggest using
>> abstract base classes rather then interfaces. You get all the advantages
>> of an interface with fewer limitations. I tend to agree with these
>> guidelines. From an abstract :-) perspective, how does an interface
>> differ from an abtract base class with no implementation?[/color]
>
> I think it comes down to your requirements and how much flexibility you
> want to allow. With an abstract base class you certainly do *not* get all
> the advantages of an interface. If you use an abstract base class you are
> forcing everyone to use that as their base if they want to play in your
> game. There are times when this would be desired. However that means
> that a class with some other base class won't be able to participate. If
> you were to instead use an interface then anyone could implement your
> interface regardless of their inheritance chain. The advantage to that is
> that two otherwise completely unrelated classes could plug into your
> design as long as they implemented your interface.
>
> I don't think anyone can make a blanket recommendation that either an
> abstract base class or an interface is always the right answer. Rather
> you must understand the strengths and weaknesses of each and make the best
> decision based on your requirements.
> --
> Tom Porterfield[/color]