First, once you see the class is implementing the IComparable interface, you know that objects of this class are comparable, based on whatever rules you define in the CompareTo method. You know that you can compare any object that implements this interface like "myobject1.compareto(myobject2)"

The details are left to you. You can compare Employees on Last name. You can compare Car types on thier price. Doesn't matter. You just know that you can always call compareto from any object that implements this interface.

As I've said before, you can build an Arraylist of type IComparable. And not care the exact type of object. You just process the Arraylist by calling the compareto method from the object in the first column and pass in the object in the 2nd column.


A principle of good interface design is to keep methods to minimum. So you don't have to have empty methods in the classes that implement them. So if you have an ISend interface that classes that only have to send via email implement, you keep the methods in this interface down to only methods needed to support sending email. If other objects will send via email or SFTP, you can create another interface that impelements the 1st interface.

Then objects that need to send via email and sftp can implement the 2nd interface as their contract.

>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