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]

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.