Re: understand the concept of interfaces

Incase the other replies dont clear the issue up for you, let me give
you my favourite example...

Let's say you are writing a little GUI widget for selecting a date from
a visual calander. The user can use the wiget to scroll to a month and
click on a date.

What you might do is create an interface, called 'Dateable' that looks
like this...

public interface Dateable
{
    void setDate(Date date);
}

and your widget code would look like this...

public class CalanderWidget
{
    private Dateable dateable;

    public CalanderWidget(Dateable dateable)
    {
        this.dateable = dateable;
        //some other stuff, setting up widget etc
    }

    //This is called when the user selects a date from the panel
    //Calling code is not shown
    private void dateSelected(Date date)
    {
        dateable.setDate(date);
    }
}

What you are saying is... "My CalanderWidget can provide a date to an
object". You dont care at all what kind of thing you are scheduling. You
could have classes like this...

public class Meeting implements Dateable
{
    public void setDate(Date date)
    {
       //some code
    }
}

or

public class NuclearLauch implements Dateable
{
    public void setDate(Date date)
    {
       //some code
    }
}

What you have done is decouple the widget from the object that is
supplying. The widget will accept any object that implements Dateable
and it knows that the setDate method will be available to use. What it
does not know (or need to know) is what other stuff is going on in the
'Dateable' class. Your widget can be used for scheduling meetings or
setting up nuclear lauches with equal ease and without changing the widget.

If you do end up scheduling a nuclear lauch though... I, for one, would
appreicate a heads up :)