Interfaces in C#

I am looking for a really simple explanation of interfaces in C#. I have been asking google but the answers I get are very technical and worded in a way a programmer might understand. It almost sounds like a method that can be called in order to perform a function, It allows the 开发者_如何学编程programmer to use less key strokes.

From what I am reading below interfaces are a way to create a container of method that do the same thing but with different technologies.

I would like to know what they are? What they do? What I might use them for?

...worded in a way a programmer might understand.

If you are not a programmer, you're going to have a little trouble understanding interfaces. Without a fairly good understanding of basic object-oriented principles, this might seem a little confusing. But onwards:

Interfaces are similar to classes, but instead of telling you what an object is it tells you what it does.

For example, a very common interface is IEnumerable. When a class implements that interface, it means that the object can create and return an Enumerator, which can be consumed by some other part of code (usually a foreach loop, or a LINQ query).

Another one you might see a lot is IDisposable. This means that you call call .Dispose() on the object and it will clean up resources. It doesn't say anything about what resources it'll clean up or what the object is -- it could be a StreamReader or a SqlConnection or something. All it says is that it has a method called Dispose.

Interfaces are very useful concepts. If you have a lot of classes that are very different but share a certain common behavior, you can have them all implement a single interface and then operate on them as one. For example, if you had an interface:

interface ICanPrintMyContents
{
    void PrintContents();
}

Then a bunch of classes that implemented them:

class ParkingGarage : ICanPrintMyContents { ... }
class UnimpressivePolitician : ICanPrintMyContents { ... }
class BankingSimulation : ICanPrintMyContents { ... }

You could put them all in a list together, even though there's no real relation between their classes.

List<ICanPrintMyContents> list = { theGarage, insertNameHere, sim1, anotherGarage };
foreach(ICanPrintMyContents item in list)
    list.PrintContents();

(Note: that ICan... naming convention is not widely used, and I don't advise it. Many people don't like it, but I'm using it here because it conveys the meaning of the interface very well. More common would be IPrintableContents or something)

Imagine that you have a pizza store (I'm stealing this example from a famous Design Patterns book). You know that all pizzas need to be ordered, prepared, baked and boxed. Well, you can define this common behavior into an interface:

public interface IPizza
{
   void Order();
   void Prepare();
   void Bake();
   void Box();
}

And have your different kinds of pizzas implement that interface. When you implement an interface, you're forcing that class to have the same methods and parameters as the interface, for example:

public class PepperoniPizza : IPizza
{
   public void Order()
   {
       //Order Pepperoni pizza
   }

   public void Prepare()
   {
       //Prepare Pepperoni pizza
   }

   public void Bake()
   {
       //Bake Pepperoni pizza
   }

   public void Box()
   {
       //Box Pepperoni pizza
   }
}

You would pretty much have the same with Hawaiian, Cheese or any other Pizza.

In real life there are several uses for Interfaces. You can create contracts to extend an application, or ensure that it works on different situations.

Hope this helps

It is simply a contract; in the sense the particular class which "implements" an interface should have all those properties and methods that interface defines. And in those properties/methods you could write whatever code, but people normally write code which do specific things.

Like for e.g. take the concept of garbage collection: if you are pertinent about controlling the way memory is released by your object you would go for implementing the IDisposable interface. This interface exposes a Dispose() method. Though programmers write the code for Dispose() they never actually call it in code. The framework does it for you.

You have to look at it from this perspective. The framework doesn't need to be aware about the details of your custom made class object. But as long as it is able to understand that that class object implements this interface it can make an call to the Dispose() method on it, and execute whatever code is there; in this case garbage collection code.

Garbage collection is a very dense topic. But what I've explained has just scraped the surface. Now if you really want to see interfaces in action you should try researching on .net remoting. Its another dense topic, but it will help you understand.

Interfaces are contracts. Declarations without implementations. They are used for loose coupling, testability and DI.

Here is a simple Real-World Example(not cats and dogs) Say you want to pull some data for your app. You create IRepository Interface like this

public Interface IProductRepository
{
   public IList<Product> GetAllProducts()
}

Than in you Implement this with some class that returns Hard-Coded Fake data(for testing)

public class FakeProductRepository : IProductRepository
{
  public IList<Product> GetAllProducts()
  {
     // create some fake product list and return it
  }
}

Let's say you are creating a Console app. In your Main Function you can do this

  IProductRepository repository = new FakeProductRepository()

and test your logic

once you are comfortable you can have a "Real" ProductRepository class that implements that interface and pulls data out of a "live" database

I'll point you to a previous answer that conceptually describes interfaces well using analogies: Why do we use Interface? Is it only for Standardization?

With the update of Arturo Molina here is the updated Interface members

public interface IPizza
    {
       void Order();
       void Prepare();
       void Bake();
       void Box();
    }

NOTE: Since Interface members are by default public and no need to mention access modifiers explicitly also it wont accept even.