Interfaces vs Classes

[tshad]

I am trying to figure out when it is best to use Interfaces and when to use
classes.

The only reason I can figure out to use interface is if you need to
implement multiple interfaces.

The problem with interfaces over classes seem to be that you need to create
multiple implementations for the same interface using interfaces (which may
be the same for all your classes).

Why would you not just implement an class where you can extend the class and
just override the classes you want to be different?

I was looking at a program from a book that set up interfaces for its
database class but then just implements the Database class itself. Not sure
why the interface was necessary.

I see a lot of discussions on Interfaces, but not a lot of discussions on
why you would use one over the other (other than the multiple interface
issue). It's one thing to know how to do it, quite another to know when to
use it (just because you can, doesn't mean you should)

Am trying to find the pros and cons of each method.

Thanks,

Tom

 

[Steve C. Orr [MVP, MCSD]]

A good example is when you create a Windows Service.
Every windows service must be able to start, stop, pause, resume, etc. And
yet those commands can mean very different things depending on the nature of
the windows service.
Therefore an interface is perfect (and is required for windows services)
because each service must implement the same set of methods and yet they are
implemented in a wide variety of ways.

Here's more info on Windows Services:
http://msdn.microsoft.com/library/d.../vbconintroductiontontserviceapplications.asp

 

[shiv_koirala]

Interface defines a contract , while classes are implementation.

C#, VB.NET , SQL SERVER , UML , DESIGN Patterns Interview question book
http://www.geocities.com/dotnetinterviews/

 

[Dennis Vroegop]

Interfaces and abstract base classes are _almost_ the same thing.
Almost, but not quite.

Let me give you a real life example.

In our current project we work with a kind of plug in system. It's all
about different developers creating pieces of functionality for one big
application.

In order to make sure the core application understands the plugins, the
developers need to implement the IPlugin interface. That way we know
that we can alway rely on having all the methods we need to instantiate
the plugin (ie. IPlugin.Instantiate, IPlugin.Draw() etc.. )

We don't care what the base classes of the plugins are. That's up to
the individual developer. We just want to use their IPlugin
capabilities.

 

[john_teague]

You are right about multiple inheritence with interfaces. That is the
only way to do it.

When to use one over the other depends on your situation. As shiv
mentioned, an interface is a contract. this means that everyone _must_
implement every method that is in the interface. And as Steve said, it
is a good way for different classes to behave differently, but still be
related.

One big draw back (for me at least) to interfaces is they are very
brittle when it comes to version changes. Say you have an interface
with 4 methods / properties and have several classes implementing that
interface. If you add or remove a method or property from the
interface, now all classes implementing it are no longer meeting their
interface contract obligations and they will not build. In some cases,
this could be a good thing.

However, if you add a new method/property to an inherited class. The
classes that inherited won't mind if there is a new method in the base
class. They will just use base implementation of the method and go on
about their business.

 

[John MacIntyre]

[snip]

One big draw back (for me at least) to interfaces is they are very
brittle when it comes to version changes. Say you have an interface

[snip]

Good point, I've often wondered how Interface changes should be handled with
version changes.

You can argue that an interface that needs changing was probably not
properly designed in the first place; but the real world indicates that it
is not only a possible change version to version but changing at least one
interface is probable.

What do you do, add the version number to the end?
IWidget
IWidget2
Or
IWidgetX

IMHO, that's an ugly hack!

Or do you just break every extension?

I suppose this is really only a problem for Frameworks (including apps which
support add-ins & customization), but I'd like to know how should this be
handled?

Looking forward to your input.

 

[tshad]

Interfaces and abstract base classes are _almost_ the same thing.
Almost, but not quite.

Let me give you a real life example.

In our current project we work with a kind of plug in system. It's all
about different developers creating pieces of functionality for one big
application.

In order to make sure the core application understands the plugins, the
developers need to implement the IPlugin interface. That way we know
that we can alway rely on having all the methods we need to instantiate
the plugin (ie. IPlugin.Instantiate, IPlugin.Draw() etc.. )

We don't care what the base classes of the plugins are. That's up to
the individual developer. We just want to use their IPlugin
capabilities.

But couldn't you do the same with Base Classes?

Set up all the Methods in the Base Class (even if the Method does nothing)
and whatever the inherited classes don't set up will use the base methods.

Tom

 

[john_teague]

Yes, I really think that Interfaces make the most sense in large-scale
frameworks. All of the work I do, which is almost completely
enterprise apps, I do not use Interfaces frequently. I tend toward
using base classes. The reason being, requirements have a tendency to
change more frequently and interfaces create more maintenance for me.


I would not use a renaming approach to new versions. I would instead
strongly name your dll and put breaking changes in a new assembly with
a different version number. That way the end user can choose which
version and which interface to implement.