Interfaces in C#

Because an interface allows you to do stuff like this....(psuedocode)

IAppliance fridge = new Fridge();  //the Fridge object implements IAppliance
TurnOnAppliance(fridge);

IAppliance washMachine = new WashingMachine();
TurnOnAppliance(washMachine);   //calling the same method, and it will work!

private void TurnOnAppliance(IAppliance appliance)
{
    appliance.TurnOn();
}

notice that the TurnOnAppliance doesn't care which appliance it is, as long as it implements IAppliance then it knows that it can call the TurnOn() method. Of coarse this is assuming that there is a TurnOn() method defined in the IAppliance interface.

it lets you abstract your objects out. You can do the same thing with inheritance, but since C# doesn't support multiple inheritance if you're already ineriting from another object then you can still get the benefit of using that object like you can with multiple inheritance

If you did it your way and then removed the interface you couldn't do that. You would have to do something like

Fridge fridge = new Fridge();
TurnOnFridge(fridge);

WashingMaching washMachine = new WashingMachine();
TurnOnWashingMachine(washMachine);

private void TurnOnFridge(Fridge fridge)
{
    fridge.TurnOn();
}

private void TurnOnWashingMachine(WashingMachine wMachine)
{
     wMachine.TurnOn();
}

notice with each new object, if they don't implement an interface (or are derrived from a common base class) then either you're going to have to do a bunch of if-then logic, or your going to have to write methods specific to each object. With interfaces, we don't have to do that as illustrated above. Derriving from a base class can do the same thing (as I said earlier) but sometimes you don't want to derrive from a base class, or sometimes you already are derriving from a base class so you have to implement an interface if you want to use OOP techniques like I showed you previously.

On a final note, if you derrive from a base class you can think "objectA IS an objectB" but with an interface you should design it so "objectA acts like objectB"

Nearly understand it.  What if we had a Comic class and a Bible class.  They both inherit the Display class so can use its Print method...So the Comic and Bible class can print without having to have their own print code within their classes.  It seems to me that with interfaces, one still has to put in all the code for the Print method within the Bible and Comic class SEPERATELY and the Interface has just A decared method called Print but no code do do the printing...  

OOPS!!! This is the link I meant to post =) I accidently gave you the google search I used to find it... sorry! =)

http://www.csharp-station.com/Tutorials/Lesson13.aspx

One quick thing...

The sample that I provided you earlier with the WashingMachine is a little misleading. It implements the IAppliance interface when actually it would be better to have an Appliance base class. Interfaces are more handy when used like IDisposable in visual studio. Any object that implements the IDisposable interface must have a Dispose method, which means that with any object that implements IDisposable we are guaranteed that the object has a Dispose method, so no matter which object it is... if it implements IDisposable we know we can call Dispose on it without knowing anything else about the object. Perhaps the WashingMachine would derrive from Appliance, but have an IElectrical interface which would have the method PlugIn(); So no matter which Appliance (or anything else that is electrical, not even Appliance objects but other objects such as Radios, or TVs) has IElectrical is guaranteed to have a PlugIn() method, no matter what. This may be handy because Appliances might plug into a certain socket, but TVs plug into a different type of socket, or appliances in a different country might yet have a different type of socket to plug into. We dont really care about that, we just care that it can plug into something electrical because it has IElectrical.

So we could have WashingMachine which is derrived from Appliance, so it can do anything a basic appliance can do at it's most basic level such as TurnOn, TurnOff...etc, but also the WashingMachine implements IElectrical so we know that we can plug it in.


 interface IElectrical
{
    void PlugIn();
}

public class WashingMachine : Appliance, IElectrical
{
    public void PlugIn()
    {
        System.Windows.Forms.MessageBox.Show("i'm plugged in!");
    }
   
    public override void TurnOn()
    {
        System.Windows.Forms.MessageBox.Show("I'm on!");
    }
}


Now say we have a 3 prong adapter that you would use so you can plug in a 3 prong plug into a 2 prong outlet, you know. It's an electrical component because it transfers electricity, but it's not an appliance, it's just a 3 prong adapter

public class ThreeProngAdapter, IElectrical
{
    public void PlugIn()
    {
        System.Windows.Forms.MessageBox.Show("I'm plugged in. Now you can plug a 3 prong cord into " +
            "this two prong outlet");
    }
}


So we have a WashingMachine and a ThreeProngAdapter. They are completely different in what they do. A WashingMachine, well washes clothes and such, but a ThreeProngAdapter doesn't. It just makes it so you can plug a 3 prong cord into a 2 prong outlet, but we can still do this...

WashingMachine wm = new WashingMachine();
PlugInComponent(wm);

ThreeProngAdapter tpa = new ThreeProngAdapter();
PlugInComponent(tpa);

private void PlugInComponent(IElectrical electricalComponent)
{
    electricalComponent.PlugIn();
}


notice that we can still run the same method on the washing machien and the adapter because they both use IElectrical. The adapter doesn't derrive from Appliance because we don't want a TurnOn() method for it, you don't really turn the adapter on. You can create some neat designs by using interfaces because two totally different types of objects can be used in the same way in certain circumstances, for example the adapter and the washing machine were both able to be passed through the PlugInComponent method despite those objects having nothing else in common. The PlugInComponent method doesn't care at all if it's an appliance, a three prong adapter, speaker wire... as long as it has IElectrical it knows that it must have a PlugIn(); method, so we're able to call it and the object that implements the PlugIn method takes care of the rest.

TYPO!!!

Sorry wasn't really paying much attention when I wrote the last post I guess...

public class ThreeProngAdapter, IElectrical

should be

public class ThreeProngAdapter: IElectrical

(no comma, in the second one)

guess i'm getting tired =)

Thanks, mate!