Well, nobody mentioned this, so you will hear it from the less appropriate person, but Interfaces are also a way to get some pseudo multiple inheritance (which it can be also bad design) for example (and it will probably stink) You might have two classes, Boat and Car, both deriving from Vehicle but now someone brings you a Car that moves in the water (or a boat that moves in the land), problem is you can not derive the new class from both (some languages do allow to do so) so the Interfaces come to the rescue, you could define a class CarBoat from Vehicle that implements IBoat and ICar. Well, that is a crude explanation, someone will give you a better example and explanation.

No, not crude, that's a very good one.

Yeah, since .NET doesn't support multiple inheritance, you can use interfaces to get around that.

The only time I've had to do that was with .NET remoting, prior to WCF. If I had a server-side class that I wanted to use for remoting (which required inheriting from System.MarshalByRefObject), AND I wanted that class to inherit from a base class, I couldn't do both, at least not directly. But with interfaces, I can do the following:

1) Define my base class to inherit from MarshalByRefObject (for remoting)

public class MyBaseBzObject : System.MarshalByRefObject

2) Define my interface for my Customer Class

public interface IMyCustomerInterface {   
       string GetCustomer(int CustomerID); 
      }

3) And then define my actual customer class to inherit from the base class, and implement the interface...

public class MyCustomerObject :  MyBaseBzObject, IMyCustomerInterface

I'm sure there are other ways to do it....but that gave me what I needed...I could activate an object of type IMyCustomerInterface (guaranteed to expose GetCustomer) and was assured that since it inherited from my base bz object, I'd get the messaging proxy for remoting.

Good discussion!
Kevin