Why 'Interfaces'?

  • Thread starter Thread starter Peter N Roth
  • Start date Start date
P

Peter N Roth

If i build a class in C#, i can declare a method abstract.
If someone derives from this class, the abstract method
must be overriden for the computation to succeed.

ISTM that an Interface provides a similar service, i.e.,
all methods must be implemented in order for the computation
to succeed.

Why use one or the other? Or maybe both?
Is it because interfaces can be implemented in _any_
language?
 
Inheritance follows the class hierarchies. And interface is a contract which
describes what members should be included in the class which implements the
interface. Interfaces cross class hierarchy boundaries. Also, a class can
only inherit from one superclass, whereas a class can implement several
interfaces.

Hope that sums it up.

Cheers,
Wim Hollebrandse
http://www.wimdows.net
http://www.wimdows.com
 
C# has no multiple inheritance, yet it has multiple interfaces,

What is the difference between having multiple interfaces and multiple base
classes with regard to problems assosicated with multiple inheritance that
is claimed why we have no multiple inheritance in C#.
 
An abstract class contains one or more abstract members.
Therfore, you could design a 90% complete class leaving
only one method undefined and requiring that non-abstract
classes that derive from it include an implementation of
the remaining method. Since .NET allows only single
ineritence of classes, the abstract class you derive from
will be the only class you derive from.

Interfaces, on the other hand, only define member
definitions. Classes that implement the interface must
implement each member of that interface, but it is
completely up the implementor how it is done.

Any class that implements an interface can be cast to that
interface. Therefore, it is possible to write methods
that operate on an interface, without knowing at design
time what kind of object you're going to be manipulating.

For example, this is how the foreach statement works in
C#. For a class to be used with the foreach statement, it
must implement the interface IEnumerable. foreach uses
the methods defined in this interface to step through the
objects in your collection. Obviously, the person who
wrote the foreach method for Microsoft didn't know
anything about the BasketOfEggs class that you were going
to write in the future, but if you implement IEnumerable
(and IEnumerator) you can write a statement like -
foreach(Egg egg in MyBasketOfEggs). It does not matter
what class Egg or BasketOfEggs derives from.

Lastly (lastly for my post, not for the subject, which is
much more expansive than I'm qualified to talk about),
there is no limit to the number of interfaces a class can
implement.

Charlie
 
Thus spake Peter N Roth:
Why use one or the other? Or maybe both?
Click to expand...

An interface is typically used where seemingly common functionality is
required for different types of objects. Since C# only allows single
inheritance, you would have to move all common abstract methods into a
single base from which all other objects implementing those methods must
derive. There are many scenarios where this would be highly inefficient
and needlessly complex.

Interfaces allow us to get around the problem in much the same way but
without inheritance. If you take a look at an existing interface such as
IList, you will see that it is implemented in 44 widely disparate .NET
classes. As such, the funcionality provided by IList can be used in a
uniform manner from any class which implements it.

Now imagine trying to develop all 44 of those classes if they had to
descend from a single base class. Interfaces make it easy to design
objects with no common ancestor and common functionality.
 
Hi Mr. Tickle,

Mr.Tickle said:
C# has no multiple inheritance, yet it has multiple interfaces,

What is the difference between having multiple interfaces and multiple base
classes with regard to problems assosicated with multiple inheritance that
is claimed why we have no multiple inheritance in C#.
Click to expand...


Consider this example:

public class Foo
{
...
public override string ToString()
{
return "Foo";
}
...
}
...
public class Bar
{
...
public override string ToString()
{
return "Bar";
}
...
}

// Let's pretend we have multiple inheritance
public class FooBar : Foo, Bar
{
...
}

Now assuming class FooBar does not implement "ToString" itself, which
implementation of "ToString" should it get, the one from "Foo" or the one
from "Bar"? If this were C++, FooBar would inherit Foo's version of
"ToString" since Foo comes first in the inheritance list. Not very
intuitive, IMO.

The above illustrates the primary *technical* problem with MI, but there
are non-technical problems with MI as well. Basically, it's one of those
things that, in practice, often leads to "yucky" code.

My $0.02.

Regards,
Dan
 
Hi Daniel,

See my comments inline.
Consider this example:

public class Foo
{
...
public override string ToString()
{
return "Foo";
}
...
}
...
public class Bar
{
...
public override string ToString()
{
return "Bar";
}
...
}

// Let's pretend we have multiple inheritance
public class FooBar : Foo, Bar
{
...
}

Now assuming class FooBar does not implement "ToString" itself, which
implementation of "ToString" should it get, the one from "Foo" or the one
from "Bar"? If this were C++, FooBar would inherit Foo's version of
"ToString" since Foo comes first in the inheritance list. Not very
intuitive, IMO.
Click to expand...

Actually calling ToString for pointer or reference of type FooBar is error
in C++ anyway. The program won't compile.

You have to cast to one of the base classes.

FooBar fb = new FooBar();
((Foo*)fb)->ToString();
or one can override ToString in FooBar and call the ToString method of the
base class of choice.

This is in case that the classes don't implicitly inherit from a common
class (Object)

If we have this Object class in this case programmers have two choices to
use virtual or non-virtual inheritance.
Anyway the laguage has standard constructions to resolve any ambiguities.


The above illustrates the primary *technical* problem with MI, but there
are non-technical problems with MI as well. Basically, it's one of those
things that, in practice, often leads to "yucky" code.
Click to expand...

How "yucky" is the code depends on how good is the design. I can write
really "yucky" code without using multiple inheritance ;)))))

Even though multipile inheritence needs to be used carefully it is verry
useful and I miss it once in a while.

However absence of multiple inheritance in .NET gives the JIT opportunity to
optimize the code better, speed up all safety checkings and so on.

B\rgds
100
 
An ineterface is a "contract" between two objects - it defines members
through which you are accessing functionality; a parent class,
however, defines a good portion of functionality on its own. Ofcourse
you could implement a class comprised of virutal methods (and in times
you do need that specific functionality).

In general you would use an abstract class to define some
functionality that requires some additional enhancements by inherited
class.
In case of interfaces, however, you would specify access methodology
to a specific class.

One of a good examples where you'd use interfaces is version control
of the code or unknown parameter to a function that required to
support only a specific set of functions.


a small example where interfaces are nearly unavoidable.

- you have an object that supplies data
- object is submitted from a client to a server (who cares what the
transport is)

public interface IMyDataSource
{
GetData();
}

Server has a function defined

public static void DataProcessor(IMyDataSource client_data)
{
//process data
}

if you need other applications to be able to supply data to you, all
you need to tell a developer is to implement IMyDataSource interface
and send you the object.

Imagine that some time after you have different version of the
function performing the same thing. You cant remove the current
funciton since you have 1000 clients out and God only knows how many
other apps implementing IMyDataSource interface.

What you do is:

public interface IMyDataSource_v2
{
GetData();
}

public static void DataProcessor(IMyDataSource_v2 client_data)
{
//process data
}

Now, those clients that implement second version of the client app
will get processed by the second function, and the first group will
not break.

If you were to use abstract class with GetData() method implemented,
you would be stuck (overloads could have helped but it would be very
messy)
 
Hi 100,

100 said:
Hi Daniel,
Click to expand...
Actually calling ToString for pointer or reference of type FooBar is error
in C++ anyway. The program won't compile.

You have to cast to one of the base classes.

FooBar fb = new FooBar();
((Foo*)fb)->ToString();
or one can override ToString in FooBar and call the ToString method of the
base class of choice.

This is in case that the classes don't implicitly inherit from a common
class (Object)
Click to expand...

In my example both Foo and Bar *do* inherit from the same base class
(Object). Hence the ToString implementations are overrides. And if you cast
to the base class and call ToString, then the compiler will have to choose
either the Foo or Bar implementation of ToString. Even though the behavior
is predictable, it still seems unnatural (to me) that a significant behavior
change could result from simply re-ordering the inheritance list.
If we have this Object class in this case programmers have two choices to
use virtual or non-virtual inheritance.
Anyway the laguage has standard constructions to resolve any ambiguities.
Click to expand...

You know, this brings up something I hadn't even thought of before. To
virtually inherit or not and the implications of that choice on behavior and
performance.

How "yucky" is the code depends on how good is the design. I can write
really "yucky" code without using multiple inheritance ;)))))
Agreed.

Even though multipile inheritence needs to be used carefully it is verry
useful and I miss it once in a while.
Click to expand...

I'll admit I'm torn on this subject. I've never been a fan of the idea
of removing or preventing something in a language just because *some* people
will misuse/abuse it. There are also times when I think it would be nice to
use MI. On the other hand, I appreciate a "clean", straightforward language
that encourages me to do "the right thing". To me, MI seems counter to those
ideals.

To summarize, I don't think MI is bad or useless. I do think it's a lot
less trivial than many people realize.

Regards,
Dan
 
How is an IEgg better than a CEgg, where CEgg is
an abstract class? I should be able to cast a CEgg
derivative to CEgg, so the superiority of one over
the other is not clear to me.

Unless this somehow goes across languages? ie, I
define an IEgg in C# and a Delphi or Eiffel
programmer can implement it and use my EggBasket.
 
Interesting page, a nice clarification.

Ideally, then, your development process
includes a 'revise' step such that you examine
your base classes for re-publication as Interfaces?

The 'contract' example recalls the Design by Contract
idea of Bertrand Meyers - "I will eventually get
around to reading that book, too!," I lied.
 
Back
Top