Kevin,

Here's another example of my confusion on the use of interfaces.

MSDN has this: http://msdn2.microsoft.com/en-us/library/system.icomparable.aspx

The example shows a Temperature class which implements the IComparable interface.
The code implements the CompareTo method.

My point is, why bother implementing the interface? Why not just create the CompareTo
method? By implementing the interface, the programmer is forced to include any
and all required members, even if he/she isn't going to implement them.








>Hey, Kevin,
>
>Here's another example of how interfaces are fundamental: in Windows Communication Foundation (WCF).
>
>Suppose you have some kind of distributed architecture. One of the modules in your app is a basic customer module, with code on the server side to retrieve client master data by a client ID, and also to retrieve client history data for a client ID.
>
>So you have two functions in a basic customer business class:
>
>

>string GetCustomer(int CustomerID);      // both return XML strings
>string GetOrderHistory(int CustomerID);
>

>
>Now, these functions will reside in a class on the server side.
>
>OK, basic stuff....but now you have the client piece, and you want the client piece to call these back-end classes. Trouble is, the client piece is on a different location/domain/server/etc, and can only access the server through TCP, or HTTP, etc.
>
>You sure don't want the client piece to have to have a copy of the server-side customer class (not only because you don't want to have to push out DLLs, but also because that customer class may be accessing a data access piece that's physically unavailable to the client piece). So you want every layer to execute code on the domain where the layer resides.
>
>So...what to do? Well, here's where interfaces come in. From a technical standpoint, what you want to do in a client piece is work with an interface to these back-end functions, like so:
>
>

>[ServiceContract]
>public interface ICustomer
>{
>    [OperationContract]
>    string GetCustomer(int CustomerID);
>    [OperationContract]
>    string GetOrderHistory(int CustomerID);
>}
>

>
>(Note the ServiceContract and OperationContract references...I'll get to them in a minute)
>
>When the client and server pieces share this simple interface, it allows the client to do the following
>
>1) In design mode, the programmer can create a proxy object that implements the interface
>2) The programmer can work with that object and use discovery (intellisense), as if the class object were local
>3) At runtime, we can use WCF to specify the actual address and communication binding (TCP, HTTP, etc.) for the proxy object.
>
>So this fits in with what Bonnie said about "programming to an interface". In this instance, the client doesn't "need" the full back-end customer class. All the client needs is an interface. The interface guarantees (and that's why people refer to an interface as a contract) that any class implementing that interface will contain specific properties and methods.
>
>So you can be confident in developing/coding against that interface, knowing that the actual back-end object will contain the same props and methods you're working with. You don't so much care "how" GetCustomer and GetOrderHistory work....you mainly care "what" you give them and receive from them: they take a customerID as a parameter, and return XML strings as results.
>
>So...hopefully that gives another explanation on the value of interfaces. In general, they are great (and basically essential) for distributed development.
>
>(If you're interested in WCF, I can post the code for the server side/client side steps for this example)
>
>Hope that helps...
>Kevin