The interface enforces the contract so you are required to implement that method otherwise the code won't compile.

THe difference is that you get a compile time error vs a runtime error if you made a mistake implementing the interface correctly.

Using interfaces is one of those things that seems a waste of time at first but quickly becomes second hand once you have the abillity to do so.

Interfaces are extremely useful for many, many things several of which have already been mentioned:

* Enforcing a class contract
* Allowing horizontal reuse
(different classes can all implement the same interface which can then
be used the same way by all clients even though classes may be completely
different - this often sidesteps the need for multiple inheritance)
* Marking a component for dynamic activation. Marker interfaces
let generic code determine if the component is allowed to do something.

+++ Rick ---

>Thanks Kevin
>
>So...hopefully that gives another explanation on the value of interfaces. In general, they are great (and basically essential) for distributed development.
>
>So, to play devil's advocate, why would I not just write a class to access the public
>members of the server side component? In other words, why not just write a class
>with
>

GetCustomerRecord(int CustomerId)

>
>regardless of the interface?
>
>
>
>(If you're interested in WCF, I can post the code for the server side/client side steps for this example)
>
>I would like that. Please do.
>
>Thanks
>
>
>
>
>
>
>>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