An interface is an aspect. For example, all cars have a steering wheel (aspect of steering) but when the steering happens the implementation differs with every manufacturer or they might not, however, a user does not care what happens in the middle. The user only cares about the interface (steering) and the outcome (wheels to turn). Interfaces in programming serve the same purpose. Different classes can have their own implementation but the input and output will always be the same. Consider this: public class Customer { Save() { ISaver saver = new DBSaver(); saver.Insert(this); // Here we are asking an implementation of Insert which inserts to the database. } } internal class DBSaver : ISaver { public void Save(Customer c) { // Here the implementation is to save to DB } } Now if your users decide they do not want to save to databases anymore but want to save to a flat file (not sure why they would do this but who cares), all you have to do is write another class which implements the interface, unit test it and then change only one line of code in Customer as below: public class Customer { Save() { ISaver saver = new FlateFileSaver(); // Only this line is changed saver.Insert(this); // Here we are asking an implementation of Insert which inserts to the flat file. } } That is it and you are good to go. Your UI is still calling CustomerObject.Save() but something different is happening--polymorphism. There are many other advantages to using Interfaces but this is the basic idea. Sometimes it also helps layout the foundation (blueprint foundation) for something. For example, I do not know how to make a good container class but if I implement the IList interface provided by .NET then I will have a good container will all the appropriate methods. Of course, you have to write good implementation because even if you write garbage inside the implementation that is what will get carried out.
