Interfaces

  • Thread starter Thread starter JJ
  • Start date Start date
J

JJ

Can someone explain to me how interfaces are such a big
help in creating objects? I was under the impression that
an Interface was a template for an Object, just sort of a
class with only method signatures
inside them, not actual code inside the methods. But from
seeing code and hearing bits and pieces from individuals,
they are more than that.
Please enlighten me oh coding gods and gurus.

Thanks,
JJ
 
In simplest terms, an interface guarantees that a class implements the
methods defined.

In other words, if you get a reference to a class that implements a given
interface, then you nkow for a fact you can call the methods defined in the
interface, no matter what the class does, or how it is otherwise defined.

This is pretty powerful when you are trying to write a generic class and
you don't care (and cannot control) what the class does, but if the class
implements a given interface, you know for a fact you can call the
interface methods.
 
So my understanding is that an Interface has no actual
code in the methods correct? and if so, when I go and
implement a textbox control in a new user control what
benefits am I getting from the textbox interface if there
is no code in it?

Thanks,
JJ
 
JJ said:
So my understanding is that an Interface has no actual
code in the methods correct? and if so, when I go and
implement a textbox control in a new user control what
benefits am I getting from the textbox interface if there
is no code in it?

In that case, if there is a function written by third party X to operate
on a textbox, then that function can also operate on your control
(without a need for third party X to modify their code for your control).
This is without you doing anything except implementing the interface.

For example, if you make a windows control from scratch, then you have to
implement certain interfaces (or inherit from a base class that
implements those interfaces) in order for the MS VisualStudio.NET IDE to
handle your class. This happens successfully even though Microsoft does
not know what your control is. All that is happening is that you
implement the interface, and so the IDE can talk to your control
successfully.
 
Right but I thought that the interface doesn't have any
code in the methods so what is it implementing?

when I see this in a class:
public class NewEmployee : System.Windows.Forms.Form
{
}

I assume that System.Windows.Forms.Form is an interface,
correct? So it must have code in it to help create a
skeleton form, correct? How does it get around not being
able to add code to the interface. I am missing something.

JJ
 
JJ said:
Right but I thought that the interface doesn't have any
code in the methods so what is it implementing?

An interface forces the implementor to implement the interface. In other
words, let's assume that (in your previous example of the textbox) your
textbox must implement the Resize(int newWidth, int newHeight) method
because you are implementing an interface.

In this case, you must code the Resize() method to resize your textbox.
You erase the old-sized textbox, you re-draw the textbox of the new size.
All the caller has to do is call the Resize() method.
when I see this in a class:
public class NewEmployee : System.Windows.Forms.Form
{
}

Here you are seeing a class that inherits from the
System.Windows.Forms.Form class (which does have it's own drawing
methods), not one that implements the System.Windows.Forms.Form interface
(there is no such thing).

On the other hand, System.Windows.Forms.Form may itself implement several
interfaces. Look into the help system, it will tell you which interfaces
a documented class implements.

Here's a c# rule of thumb: You can inherit from one or none base
classes, but you can implement as many interfaces as you want. Now you
start getting into multiple inheritance issues, which you should
investigate when you have a firm understanding of interfaces. You only
need to liik into multiple inheritance (inheritign from more than one
base class) if you would like to find a justification of why c# allows
inheriting from a single base class and no more.
 
No, in that case, System.Windows.Forms.Form is a class and NewEmployee is
inheriting from the class.

Though i believe the syntax for saying that a class implements an interface
is the same - just happens that the thing on the right side of the : is a
class, not an interface.

There's no code in an interface. It is simply a contract that states that
any object that says that it implements that interface must have these
available methods.
For instance, you might have an interface (say... IWriteContents) that
requires all implementers to have a function like
void WriteContents()
then, you could write a function whose parameter was that interface you just
wrote. Something like

private void DoWriteContents(IWriteContents iwc)
{
....
}
So inside that fucntion, you wouldn't care anything at all about the type of
object that it was - just that you could guarantee that you could make the
call
iwc.WriteContents();
and the object that was passed in would have that function for you to call.

(someone correct me if i'm misstating anything here. I haven't worked with
interfaces much, but i have read a decent amount on them... i'm just going
by memory though)

HTH,

Tim
 
Interfaces are usefull when you are designing a solution that has
"pluggable" components. That is componants the all implement the same
interface but perform difrent functionality when the interface method is
invoked. In a system like this, the system would be coupled to the interface
and use a factory design pattern to return instances of the interface as
needed. To add more flexibility to a system like this, one could place the
interface implementing classes in the app/web.config file and use reflection
to create an instance and return the implemento from the factory method.
Hope this helps! :)
 
Hmm. If you are familiar with callbacks in C, then you know that a
generic
quicksort can be implemented by using a callback function. The quicksort
method takes a pointer to the callback function. The callback function
declaration looks like a function prototype. You pass a pointer to the
function
to the quicksort routine and then implement the compare logic in the
callback
function. Now you can reuse the quicksort routine with your specific
compare
function.

Now try to do this in C#. You use the interface IComparible and create a
usefull class that implements the IComparible interface. You can now
sort an
array of these IComparible objects using Array.Sort. You implement the
compare logic in the class. Now you are reusing the Array.Sort
algorithm!

<g>

Regards,
Jeff
 
Back
Top