Another good example I've seen that helps to explain the need for interfaces is in Design Patterns.

I can't recall the name of the design pattern in question, but the example revolves around a system to handle a cash register at a coffee shop. You have the class which is the type of coffee asked for (blend, decaf, espresso, etc.).

Then you have all the associated condiments or types (whipped, cream, sugar, etc.)

The system design in this example calls for all classes to implement the same interface. For this example the interface will have 2 methods, Build and GetCost. This gets back to the previous comment about Polymorphism. The process for building the cup of coffee, getting the total cost, etc. is to build a collection of type of your interface.

Then you can interate thru the collection and you will know that all your objects will have a method of Build and a method of GetCost.

PF

>Thanks Bonnie that was very helpful as well. The light is getting brighter...Thanks!
>
>Shawn
>
>>Shawn,
>>
>>I hope Kevin doesn't mind me jumping in here. I have a standard real-world example that I've used in the past to explain the concept of Interfaces. Kevin's example was good, but I thought you'd like another example also:
>>
>>One of the biggest benefits of using Interfaces (in my opinion) is to be able to "program to the Interface", as they say. Let me explain with a real-world example:
>>
>>Suppose I have created this Interface:
>>

>>public interface IFillFromFinder
>>{
>>	void FillListView(DataSet dsList);
>>	void ClearListView();
>>}
>>

>>Now, suppose I have a class that contains a ListView and implements the Interface:
>>

>>public class MySearchClass : MyUserControl, IFillFromFinder
>>{
>>	#region Declarations
>>
>>	protected ListView     oListView;
>>	protected MyFinderForm oFinder;
>>
>>	#endregion
>>
>>	#region Methods
>>
>>	public void Search(ListView listView)
>>	{
>>		this.oListView = listview;
>>		this.ClearListView();
>>
>>		this.oFinder = new MyFinderForm(this);
>>		oFinder.ShowDialog();
>>	}
>>
>>	// Interface methods to implement
>>	public void ClearListView()
>>	{
>>		// code here for clearing listview
>>	}
>>
>>	public void FillListView(DataSet dsList)
>>	{
>>		// code here for filling listview
>>	}
>>
>>	#endregion
>>}
>>

>>As you can see, this class calls a Finder dialog Form, that gathers information from the User and performs a query against the backend data. If the Finder Dialog has been called from a control that implements this Interface (as in the above call from the Search() method), then it can also fill that control's ListView object by calling the methods on the Interface.
>>
>>Here's the relevant part of my Finder Dialog. Note that the oListControl is defined using the Interface. MyFinderForm needs to know absolutely nothing else about what's calling it, other than that it implements the IFillFromFinder interface.
>>

>>public class MyFinderForm : MyDialogForm	
>>{
>>	#region Declarations
>>
>>	public  MyListDataSet   oData = new MyListDataSet();
>>	protected IFillFromFinder    oListControl = null;
>>
>>	#endregion
>>
>>	#region Constructors
>>
>>	public MyFinderForm(IFillFromFinder CallingControl)
>>	{			
>>		this.oListControl = CallingControl;			
>>		InitializeComponent();
>>	}		
>>
>>	public MyFinderForm()		
>>	{			
>>		InitializeComponent();
>>	}
>>
>>	#endregion
>>		
>>	#region Events
>>
>>	private void cmdOK_Click(object sender, System.EventArgs e)
>>	{
>>		this.FillDataSet();
>>
>>		// If this dialog form was called by a class that implemented IFillFromFinder,
>>		// then call call the Interface method to fill the ListView.
>>		if (this.oListControl != null)
>>		{
>>			if (this.chkReplace.Checked == true)
>>				this.oListControl.ClearListView();
>>			this.oListControl.FillListView(this.oData);
>>		}
>>	}
>>
>>
>>	#endregion
>>}
>>

>>I hope this sort of helps explain interfaces by using a real world example.
>>
>>~~Bonnie