What is the difference between an interface and a class, and why I should use an interface when I can implement the methods directly in the class?

Question

Interfaces are excellent when you want to create something like it:

using System;

namespace MyInterfaceExample
{
    public interface IMyLogInterface
    {
        //I want to have a specific method that I'll use in MyLogClass
        void WriteLog();       
    }

    public class MyClass : IMyLogInterface
    {

        public void WriteLog()
        {
            Console.Write("MyClass was Logged");
        }
    }

    public class MyOtherClass : IMyLogInterface
    {

        public void WriteLog()
        {
            Console.Write("MyOtherClass was Logged");
            Console.Write("And I Logged it different, than MyClass");
        }
    }

    public class MyLogClass
    {
        //I created a WriteLog method where I can pass as a parameter any object that implements IMyLogInterface.
        public static void WriteLog(IMyLogInterface myLogObject)
        {
            myLogObject.WriteLog(); //So I can use WriteLog here.
        }
    }

    public class MyMainClass
    {
        public void DoSomething()
        {
            MyClass aClass = new MyClass();
            MyOtherClass otherClass = new MyOtherClass();

            MyLogClass.WriteLog(aClass);//MyClass can log, and have his own implementation
            MyLogClass.WriteLog(otherClass); //As MyOtherClass also have his own implementation on how to log.
        }
    }
}

In my example, I could be a developer who writes MyLogClass, and the other developers, could create their classes, and when they wanted to log, they implement the interface IMyLogInterface. It is as they were asking me what they need to implement to use WriteLog() method in MyLogClass. The answer they will find in the interface.

One reason I use interfaces is because it increases the flexibility of the code. Let's say we got a method that takes an object of class type Account as parameter, such as:

public void DoSomething(Account account) {
  // Do awesome stuff here.
}

The problem with this, is that the method parameter is fixed towards an implementation of an account. This is fine if you would never need any other type of account. Take this example, which instead uses an account interface as parameter.

public void DoSomething(IAccount account) {
  // Do awesome stuff here.
}

This solution is not fixed towards an implementation, which means that I can pass it a SuperSavingsAccount or a ExclusiveAccount (both implementing the IAccount interface) and get different behavior for each implemented account.

Interfaces are contracts that implementers must follow. Abstract classes allow contracts plus shared implementations - something that Interfaces cannot have. Classes can implement and inherit multiple interfaces. Classes can only extend a single abstract class.

Why Interface

• You don't have default or shared code implementation
• You want to share data contracts (web services, SOA)
• You have different implementations for each interface implementer (IDbCommand has SqlCommand and OracleCommand which implement the interface in specific ways)
• You want to support multiple inheritance.

Why Abstract

• You have default or shared code implementation
• You want to minimize code duplication
• You want to easily support versioning

So in this example, the PowerSocket doesn't know anything else about the other objects. The objects all depend on Power provided by the PowerSocket, so they implement IPowerPlug, and in so doing they can connect to it.

Interfaces are useful because they provide contracts that objects can use to work together without needing to know anything else about each other.

In one word - because of Polymorphism!

If you "Program to an Interface, not an Implementation" than you can inject different objects which share the same interface(type) into the method as an argument. This way your method code is not coupled with any implementation of another class which means it's always open to work with newly created objects of the same interface. (Open/Close Principle)

• Look into Dependency Injection and definitely read Design Patterns - Elements of Reusable Object-Oriented Software by GOF.

I believe that many blood was already spilled in asking this questions, and many tries to resolve this issues by explaining robot-like terms that no normal human can understand.

So First. to learn why interface and why abstract you need to learn what are them for. I personnaly learned this two when applying Factory Class. you find a good tuturial on this link

Now let's dig-in base on the link I already gave.

You have Vehicle class that might change upon user requirement (like adding Truck, Tank, Airplane, etc. And given we have

public class clsBike:IChoice
{
   #region IChoice Members
    public string Buy()
    {
       return ("You choose Bike");
    }
    #endregion
}

and

public class clsCar:IChoice
{
   #region IChoice Members
    public string Buy()
    {
       return ("You choose Car");
    }
    #endregion
}

and both has Contract IChoice that simply say My Class should have Buy method

public interface IChoice
{
    string Buy();
}

Now, you see, that interface only enforce the method Buy() but let the inherited class decide what to do when they implement it. This is the limitation of Interface, using purely interface, you might end up repeating some task that we can implement automatically using abstact. On our example let say, buying each vehicle has a discount.

public abstract class Choice
{
    public abstract string Discount { get; }
    public abstract string Type { get; }
    public string Buy()
    {
       return "You buy" + Type + " with " + Discount;
}
public class clsBike: Choice
{
    public abstract string Discount { get { return "10% Discount Off"; } }
    public abstract string Type { get { return "Bike"; } }
}

public class clsCar:Choice
{
    public abstract string Discount { get { return " $15K Less"; } }
    public abstract string Type { get { return "Car"; } }
}

Now using the Factory Class, you can achieve the same thing but in using abstract, you let the base class execute the Buy() method.

In Summary : Interface contracts let the inherit class do the implementation while Abstract class Contracts may initialize the implementation (which can override by Inherit class)