What is the purpose / benefit of using an interface statement?

It doesn't seem like anything more than a different way to make a class...
(except you can't define any procedures in an interface like you can do in a
class).

I'm obviously missing something...

John

An interface allows you to specify methods, properties and fields that
a classes that implement the interface must expose. This allows you to
write code that usilises these known elements within the class without
actually knowing about the class.

Have a look at this on MSDN:

http://msdn.microsoft.com/library/de...Interfaces.asp

Hope this helps

Blu

"John" <(E-Mail Removed)> wrote in message
news:953F14E3-DF12-462F-91B4-(E-Mail Removed)...
> What is the purpose / benefit of using an interface statement?
>
> It doesn't seem like anything more than a different way to make a class...
> (except you can't define any procedures in an interface like you can do in
> a
> class).
>
> I'm obviously missing something...
>

The reason is that it turns out to be tricky to allow a class to inherit
storage and method implementations from multiple base classes. C++ does it,
but many people think it causes as many problems as it solves. Java and
..NET use interfaces to get 90% of the benifit of multiple inheritence with
10% of the complexity. Interfaces provide a simple mechanism for a type to
derive from multiple base types without introducting the difficulties of
virtual functions up and down multiple seperate inheritence hierarchies.

David

"BluDog" <nospam> wrote in message
news:(E-Mail Removed)...
> An interface allows you to specify methods, properties and fields that
> a classes that implement the interface must expose. This allows you to
> write code that usilises these known elements within the class without
> actually knowing about the class.
>

But a MustInherit class does this, plus you can add method implementations
and data storage.

David

"John" <(E-Mail Removed)> wrote
> What is the purpose / benefit of using an interface statement?
>
> It doesn't seem like anything more than a different way to make a class...
> (except you can't define any procedures in an interface like you can do in a
> class).
>
> I'm obviously missing something...


Interfaces are simply a contract for service. When any object declares
that they support an interface, it simply means there is a group of
properties and routines that are guaranteed to be present. The combination
of properties or routines are listed in the interface so that every object
that supports that interface has a group of properties and routines that
are all identically named, as listed in the interface declaration.

Interfaces can be implemented by completely different objects, which is what
makes them very useful. You can have a car and a house both implement a
ManufacturedItem interface that lists things like Color, Date, Time and
Place of Manufacture, Retail Cost, and so on. The beauty of this is that
you can put all such objects in a list, and get a total cost, for example,
without having to know what each individual item is. As long as they all
support the same ManufacturedItem interface, you can call into them to
get their cost value, or other such properties from the interface, without
actually knowing what type of object it is. If it supports an interface,
you can declare a variable as that interface, and assign those objects to
it. Because of the contract, it will respond to calls made on that interface.
For all practical purposes, it looks like an object that was declared as that
interface type.

Going a little deeper into OO, an interface also provides the mechanism for
giving objects a chameleon effect. That is, they can look to be like an object
of many different types by supporting many different interfaces. A document
object, for example, might represent itself as a text document, an HTML document,
a letter, a fax, a report document, a chart, a graph, or other such items by
supporting the interfaces for those different types. I don't know if there are
such interfaces for those types, but for the sake of explanation, you will have
to imagine there are such document interfaces, and that a document you create
can support many such interfaces. Those looking to find a text document will
see it as a text document, and those looking to find an HTML document will see
it as an HTML document, and so on, for all the different interfaces it supports.

Supporting many different interfaces becomes useful when you have a storehouse
of routines that can produce specific output from specific objects. For example,
because this document supports the previous list of interfaces, it can be passed
to a form that knows how to display text documents, or to a browser that knows
how to display HTML documents, or to a printer that can handle letters, or a fax
machine that send faxes, or a spreadsheet that handles reports, or to other such
devices that know what to do with charts and graphs. Because that one object
supports all these different interfaces, it can be passed without modification
to many different routines that (in this case) produce output in their own
specific domains. In OO circles, the correct term for that ability is called
polymorphism.

HTH
LFS

Oh boy... I remember being where you are right now. It took forever for
me to 'get' the concept. Perhaps this will help:

All cars have a dashboard, right? And in that dashboard you always see
a speedometer and a gas guage, right? Ok... Those requirements are the
dashboard INTERFACE.

Some cars measure speed by running a cable from the transmission. Some
cars measure speed by running a cable from the wheel. Some cars
(perhaps) measure speed by a little propeller on the roof.

Your dashboard interface does not care HOW the speed is measured, as
long as it receives an value from the measuring device that you can
display on your speedometer. Same thing for the gas guage.

What your dashboard interface WON'T allow is a situation where you don't
have a speedometer and a gas guage. Your dashboard may have many other
features like a tachometer and a odometer, but in order to qualify as
one of your dashboards, it must have both a speedometer and a gas guage.

----

Ok.. That's the concept. The real question you ask, which is what
stumpped me for months, is WHY and WHEN would you use it?

Any time you are writing a class where you REQUIRE a minimum set
properties and methods to be present, you create an interface.

I use interfaces with a bunch of UserControls I have created. All of my
controls do different things and look different, but they all have a
property called IsNull. How each control determines if it is null
varies from one to the next, but in my main program, where I use many of
these UserControls I can simply call the IsNull property and get a
boolean value returned. All of my controls implement this interface so
I am guaranteed that the IsNull property will be present.

Hope this helps... It took several explanations and months fo playing
before it really clicked for me, so don't dispair... you'll get it
eventually!

--Zorpie

*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!

Ahhhh...

So interfaces are the way to inherit from more than one class. That makes
sense.

Thanks David.

John

"David Browne" wrote:

>
> "John" <(E-Mail Removed)> wrote in message
> news:953F14E3-DF12-462F-91B4-(E-Mail Removed)...
> > What is the purpose / benefit of using an interface statement?
> >
> > It doesn't seem like anything more than a different way to make a class...
> > (except you can't define any procedures in an interface like you can do in
> > a
> > class).
> >
> > I'm obviously missing something...
> >
>
> The reason is that it turns out to be tricky to allow a class to inherit
> storage and method implementations from multiple base classes. C++ does it,
> but many people think it causes as many problems as it solves. Java and
> ..NET use interfaces to get 90% of the benifit of multiple inheritence with
> 10% of the complexity. Interfaces provide a simple mechanism for a type to
> derive from multiple base types without introducting the difficulties of
> virtual functions up and down multiple seperate inheritence hierarchies.
>
> David
>
>
>
>

"John" <(E-Mail Removed)> wrote
> Ahhhh...
>
> So interfaces are the way to inherit from more than one class. That makes
> sense.

But it doesn't work in .Net.

Inheritance includes behaviour (actual working code behind the interface)
which is not supported in .Net for any more than one base object.

HTH
LFS

Thanks everybody. Those are great explanations. Much better than the MS
Help files!

I appreciate you all taking the time to respond with well thought out answers.
I look forward to trying interfaces on my next project!

John

"ZorpiedoMan" wrote:

> Oh boy... I remember being where you are right now. It took forever for
> me to 'get' the concept. Perhaps this will help:
>
> All cars have a dashboard, right? And in that dashboard you always see
> a speedometer and a gas guage, right? Ok... Those requirements are the
> dashboard INTERFACE.
>
> Some cars measure speed by running a cable from the transmission. Some
> cars measure speed by running a cable from the wheel. Some cars
> (perhaps) measure speed by a little propeller on the roof.
>
> Your dashboard interface does not care HOW the speed is measured, as
> long as it receives an value from the measuring device that you can
> display on your speedometer. Same thing for the gas guage.
>
> What your dashboard interface WON'T allow is a situation where you don't
> have a speedometer and a gas guage. Your dashboard may have many other
> features like a tachometer and a odometer, but in order to qualify as
> one of your dashboards, it must have both a speedometer and a gas guage.
>
> ----
>
> Ok.. That's the concept. The real question you ask, which is what
> stumpped me for months, is WHY and WHEN would you use it?
>
> Any time you are writing a class where you REQUIRE a minimum set
> properties and methods to be present, you create an interface.
>
> I use interfaces with a bunch of UserControls I have created. All of my
> controls do different things and look different, but they all have a
> property called IsNull. How each control determines if it is null
> varies from one to the next, but in my main program, where I use many of
> these UserControls I can simply call the IsNull property and get a
> boolean value returned. All of my controls implement this interface so
> I am guaranteed that the IsNull property will be present.
>
> Hope this helps... It took several explanations and months fo playing
> before it really clicked for me, so don't dispair... you'll get it
> eventually!
>
> --Zorpie
>
> *** Sent via Developersdex http://www.developersdex.com ***
> Don't just participate in USENET...get rewarded for it!
>