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?

I am aware that this is a very basic question, but an interviewer asked me in a very trick way and I was helpless :(

I know only material or theoretical definition for an interface and also implemented it in many projects I worked on. But I really don't understand why and how is this useful.

I also don't understand one thing in interface. i.e for example, we use

conn.Dispose(); in finally block. But I don't see that class is implementing or inheriting IDisposable interface (SqlConnection) class I mean. I am wondering how I can just call the method name. Also in the same thing, I am not understanding how Dispose method works as because, we need to implement the function body with our own implementation for all interface methods. So how Interfaces are accepted or named as contracts? These questions kept on rolling in my mind till now and frankly I never saw any good thread that would explain my questions in a way that I can understand.

MSDN as usual looks very scary and no single line is clear there (Folks, kindly excuse who are into high level development, I strongly feel that any code or article should reach the mind of anyone who see it, hence like many others say, MSDN is not of use).

The interviewer said:

He has 5 methods and he is happy to implement it in the class directly, but if you have to go for Abstract class or interface, which one you choose and why ? I did answered him all the stuffs that I read in various blog saying advantage and disadvantage of both abstract class and interface, but he is not convinced, he is trying to understand "Why Interface" in general. "Why abstract class" in general even if I can implement the same methods only one time and not gona change it.

I see no where in net, I could get an article that would explain me clearly about interfaces and its functioning. I am one of those many programmers, who still dont know about interfaces (I know theoretical and methods I used) but not satisfied that I understood it clearly.

Solution 1:

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.

Solution 2:

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.

Solution 3:

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

Solution 4:

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.