Trying to understand the purpose of interfaces

[Bruce Wood]

Do interfaces get used in ASP.NET or is that more of an executable world?

Well, I don't write for ASP.NET, but yes, they would be used there,
too.

Rather than talking about ducks, I'd rather point out a classic use of
interfaces: your business layer needs to talk to a data layer in order
to persist / fetch business information. Typically what one does here
is write a bunch of Data classes that mediate between the business
layer objects and their representation in a SQL database. No problem so
far.

Now say that I want to demo my product on the road, and I don't
necessarily have access to a SQL database. I could, of course, use a
lightweight SQL database product on my laptop, but another option is to
write a whole other data layer that doesn't use a relational database
on the back end. Perhaps I want to store some demo data in XML files
and read from them instead. How would I do that?

Well, my SQL database persistence classes have their own inheritance
hierarchy: CustomerSqlData, say, inherits from SqlDataHandler, which
has lots of functionality common to classes that need to talk to SQL
databases. If I inherit CustomerXmlData from SqlDataHandler, or from
CustomerSqlData, then I get a bunch of code that has to do with SQL
databases that I don't want. If I create a whole second inheritance
hierarchy--CustomerXmlData inherits from XmlDataHandler--then how do I
tell my business layer that CustomerSqlData and CustomerXmlData are
really the same thing, just implemented in two different ways?

Interfaces are the answer. I create an interface called ICustomerData,
and simply tell my business layer class that it is talking to an
ICustomerData object. It doesn't need to know which one. The objects
don't need to be related by inheritance. In effect, my business layer
object is specifying a _contract_: "I will deal with any object that
implements the following functionality..." rather than specifying a
particular _class_ with which it will work. This frees you to implement
the required functionality in any class, anywhere in the inheritance
hierarchy, and effectively you can "plug and play" your data layer into
your business layer. You can even plug in some data classes that read
from XML and some that read from SQL if that turns out to be useful.

Interfaces, then, give you the capability to "chunk off" parts of your
application and build plug-and-play parts to implement the various
chunks. Each layer of your application knows only that the object it's
talking to implement the required contract (interfaces).

This sort of layering and plug-and-play capability applies equally well
to ASP.NET and WinForms.

 

[Bruce Wood]

This may be dumb, but say I had some method that took the parameter:

public void RunAppliance (IOutlet electricalAppliance)
{
electicalAppliance.TurnOn();
}

As long as the electicalAppliance class reference sent to the method
RunAppliance implements the IOutlet interface then objects like::

refrigerator
toaster
tvset

all can/must use the method TurnOn() in there respective classes. Now
if I knew every single electrical appliance that would ever be designed
had a TurnOn() method, then I may not need the Interface, but if I did
not have the Inteface, then I would have to do something like you did
above with (object electricalAppliance) and do all sorts of tests on
every single possible appliance.

Because I have an Interface I, a) know the contract and that anything
that implements the IOutlet interface must have a TurnOn() method, b)
because of this I can created a reference like (IOutlet
electricalAppliance) and be sure at compile time all reference are
"clean."

The advantage, I'm sure there are others, is in the ability to not have
know every single thing about a given class except that it implements
IOutlet and therefore all these otherwise unrelated classes now have
something in common. They implement the same interface.

This also helps me kind of see why there are muliple interfaces that
can be implemented. I can see why some or all appliances might turn
on, but not all heat up. A stove and toaster might have a IHeatUp
inteface, but a refrigator probably won't. We need these unique but
properties and methods for the uninherited classes that are not related
in a hierachy, but they are related in a implementation. They all do
something called the same thing, just differently.

I think I'm still missing some of it, but I think I have a better
understanding of it. Sorry if I repeated myself too much and being
long winded. It was more for me than anything. Hopefully some of it
is even right!

By Jove, he's got it!

Yes, that's exactly it. Looking at it the other way around, interfaces
allow you to design your class hierarchy according to what things
really are (is-a relationships) rather than artificial concerns about
shared functionality. In your example, it doesn't require you to lump
the Light class in with the ToasterOven class just because they both
use electricity and both need to be turned on. It allows you to put the
WoodBurningStove under the Oven class along with the ToasterOven
without worrying about how it's going to implement TurnOn().

Of course, these things often aren't clear from the outset of class
design. What initially looks like a perfectly reasonable assumption
(all appliances can be TurnedOn) may later turn out to be false, at
which point one typically extracts a method into an interface and has
all existing classes implement the interface before adding into the
hierarchy the new class that's the exception to the rule. It's called
refactoring, and it goes on all the time.

Nonetheless, whether at the beginning of the design process or later
due to refactoring, interfaces are indispensible in single-inheritance
languages such as C# and Java. A multi-interitance language such as C++
accomplishes this in a different way.

 

[Otis Mukinfus]

Thank you.

Why wouldn't I have an abstract class and override the abstract method,
since all the obects inherit from the same top level object (ducks)?

jm,

Thank you for asking this question.

The rest of you that helped answer the question and especially Bruce Wood for
one of the best and most understandable explanations of interfaces I've read. It
lit up some ILightBulb Interfaces in this old brain.
Good luck with your project,

Otis Mukinfus
http://www.arltex.com
http://www.tomchilders.com

 

[Tim Rowe]

Take the duck example that was given by another poster. Do you really
want a RubberDuck inheriting from Duck? What if Duck inherits from
FlyingBird which inherits from Bird which inherits from Mammal?

So now everybody understands interfaces, but we're all wondering why
Bird inherits from Mammal

 

[Tim Rowe]

languages such as C# and Java. A multi-interitance language such as C++
accomplishes this in a different way.

Although, of course, users of those multiple-inheritance languages often
choose to so it the same way, because it's so often the Right Thing to
do -- it's not uncommon to have C++ classes with no members and all
methods abstract, which is essentially the C++ way to have an interface.

 

[jm]

Well, I don't write for ASP.NET, but yes, they would be used there,
too.

Rather than talking about ducks, I'd rather point out a classic use of
interfaces: your business layer needs to talk to a data layer in order
to persist / fetch business information. Typically what one does here
is write a bunch of Data classes that mediate between the business
layer objects and their representation in a SQL database. No problem so
far.

Now say that I want to demo my product on the road, and I don't
necessarily have access to a SQL database. I could, of course, use a
lightweight SQL database product on my laptop, but another option is to
write a whole other data layer that doesn't use a relational database
on the back end. Perhaps I want to store some demo data in XML files
and read from them instead. How would I do that?

Well, my SQL database persistence classes have their own inheritance
hierarchy: CustomerSqlData, say, inherits from SqlDataHandler, which
has lots of functionality common to classes that need to talk to SQL
databases. If I inherit CustomerXmlData from SqlDataHandler, or from
CustomerSqlData, then I get a bunch of code that has to do with SQL
databases that I don't want. If I create a whole second inheritance
hierarchy--CustomerXmlData inherits from XmlDataHandler--then how do I
tell my business layer that CustomerSqlData and CustomerXmlData are
really the same thing, just implemented in two different ways?

Interfaces are the answer. I create an interface called ICustomerData,
and simply tell my business layer class that it is talking to an
ICustomerData object. It doesn't need to know which one. The objects
don't need to be related by inheritance. In effect, my business layer
object is specifying a _contract_: "I will deal with any object that
implements the following functionality..." rather than specifying a
particular _class_ with which it will work. This frees you to implement
the required functionality in any class, anywhere in the inheritance
hierarchy, and effectively you can "plug and play" your data layer into
your business layer. You can even plug in some data classes that read
from XML and some that read from SQL if that turns out to be useful.

Interfaces, then, give you the capability to "chunk off" parts of your
application and build plug-and-play parts to implement the various
chunks. Each layer of your application knows only that the object it's
talking to implement the required contract (interfaces).

This sort of layering and plug-and-play capability applies equally well
to ASP.NET and WinForms.

"The objects
don't need to be related by inheritance. In effect, my business layer
object is specifying a _contract_: "I will deal with any object that
implements the following functionality..."

Very helpful. Thank you again.

One of the things that was baffling me was constanting thinking about
inheritance. All of a sudden interfaces broke that "rule" that was in
my mind. If I undersand correctly, I can now think of related
behaviors and properties that objects have and not strictly "is-a"
relationships and inheritance.

But one thing that doesn't make total sense to me is that if I have
ClassA and ClassB is derived from ClassA, then I can do things like:

ClassB b = new ClassB();
ClassA a = b; //I thought I could do this anyway

because ClassB is a ClassA.

With interfaces, I can now assign objects that implement the same
interface to a reference type of that interface. That throws me
because the objects are not really related except by behavioral
aspects. If ClassA and ClassB are not "kin," but both implement
IMyInterface, then I can assign them to a reference of type
IMyInterface. I know it is allowed, but it seems the total opposite of
all the other "is-a" class stuff I already had neatly tucked away with
the whole inheritance thing. On the other hand, if I go to use these
items that implement the same interface, what am I saying other than I
want to use the methods they all have in common, which does make sense.
Perhaps it is two sides of the coin of inheritance.

Don't worry if you don't understand what I'm saying. I'm more rambling
than anything It basically says, I think, that it kind of blows up the
inheritance model to assign unrelated (by inheritance) items to the
same reference type (yet they are sort of related by behavior)..

 

[jm]

Although, of course, users of those multiple-inheritance languages often
choose to so it the same way, because it's so often the Right Thing to
do -- it's not uncommon to have C++ classes with no members and all
methods abstract, which is essentially the C++ way to have an interface.

Now my problem is that I want to write a bunch of interfaces and don't
have a way to apply it. I wanted to play with my new toys. I
mentioned asp.net in another thread, and I know this is naive, but I've
been so brainwashed that I can't even think of a whole lot to do with
an executable on the desktop anymore, yet my computer is chock full of
them. Games, embedded systems, this browser. Big stuff. I'm afraid
I'll never get to use what I learned. I'll be looking everywhere for
interfaces now..at least until next chapter which is on Generics. Then
i'll try an find that.

 

[Bruce Wood]

So now everybody understands interfaces, but we're all wondering why
Bird inherits from Mammal

Ummm... it's all of those furry, warm-blooded birds flying about....
(He says, trying desperately to save face....)