I see. Thanks for the example. It doesn't seem like I do anything similar to any of the examples I have read.

>Here is a concrete example of how we use them.
>
>We host an app that customers access via the internet. One of the things we do is import files from our customers for additional processing. Sometimes we can import the files 'as is'. Most of the time we must 'massage' the file or the data in it.
>
>Our import process implements 4 hooks, pre-file, pre-transaction, post-transaction, and post-file.
>
>The Import Process checks the customer table to see if that customer has a custom DLL. If they do, it instantiates the class and calls each hook at the appropriate point in the process. Since I know the custom class implements our 'hook interface' I KNOW what methods are available, I don't need reflection, so the coding in the import app is very straight forward.
>
>I originally attempted to implement this with an abstract class, but could not get it to work (I was a .NET novice at that time, still am!). A co-worker suggested trying an interface. That worked, so that is what we marched on with.
>
>>All right, thanks. I need to let this all soak in. Maybe I should just start using them and hopefully they make sense along the way.
>>
>>>Let me preface this with 'I am no expert'.
>>>
>>>In the last app I wrote, I implemented that functionality in classes, because I knew I was always going to write to the same data store and the code was very generic for that datastore.
>>>
>>>If I thought I would ever have to write to different or multiple datastores, I think I would implement that functionality via interfaces, because the implementation is likely to be different for each one.
>>>
>>>>So if my objects are loaded and saved to a database, should I have them use an interface with Save(), Load(), Delete(), etc? Maybe I get confused because I am maintaining code that ineffectively uses them.
>>>>
>>>>>Here is the best explanation I've read...
>>>>>
>>>>>"...think at a much higher level. When you're designing an object model:
>>>>>
>>>>>* interfaces describe "can do" relationships.
>>>>>* abstract classes describe "is a" relationships.
>>>>>
>>>>>Or, to put it another way
>>>>>
>>>>>* interfaces share appearance but not implementation
>>>>>* abstract classes share both appearance and implementation
>>>>>
>>>>>When you're trying to decide whether to use an interface or an abstract class, ask yourself:
>>>>>
>>>>>* is there any situation where two COMPLETELY different objects would need to be treated as the same?
>>>>>
>>>>>* is there a fundamental "core" of implementation that needs to be shared by EVERY implementation?
>>>>>
>>>>>* is there a sensible "is a" relationship? A Giraffe IS A Mammal IS AN animal.
>>>>>
>>>>>* is there a sensible "can do" relationship? A Bitmap CAN DO disposal. "
>>>>>
>>>>>Eric Lippert
>>>>>
>>>>>from http://discuss.techinterview.org/default.asp?joel.3.89283.9
>>>>>
>>>>>Our application allows for customization on a per-client basis. We define a class that implements an interface for the customization. The class is instanciated using a factory method. Because it implements an interface, we know what methods are available and can call them appropriately, however, the implementation is different for each customer. I tried to implement this with an abstract class but had trouble getting it to work. No problems with an interface.
>>>>>
>>>>>
>>>>>>I know there was a thread a few weeks ago, but I can't find it.
>>>>>>
>>>>>>I have been reading about interfaces, and I understand the concept, but my question is "So What?" I just don't see them being helpful other than to enforce standards. Should all of my classes have an interface? What does that gain me?
>>>>>>
>>>>>>Also, when should I use an interface as opposed to inheritance? I am just not "getting" it and I figured it was about time to do something about it.