A simple example is that a good use of an Interface is for a class that will exist in many forms to account for the various processing needs of your app. For example if you have an accounting app that's sold to various clients and you've customized the app for each client.

If you have a various business logic classes for the different clients, you'd want to create an interface the class needs to implement. So if each client has various schemes they want to employ for setting rules on Invoice amount, you define and InvoiceAmount method in the Interface.

If you ensure every business logic class implements the Interface, you are guaranteed that you can call the InvoiceAmount method from the Amount validation method or Save method, etc.

This is as Bonnie says "Programming to the Interface, not the implementation". You don't care how the logic works, what specific class the object is, etc. You do know that every business class has that method. So the code for the Invoice module is clean. No "if cust A call this class, if cust B call this class, etc. Much, much cleaner.

One of the big pluses, is when a client requests a change to the logic, you only change the business logic class that instantiates for them. With no changes to the actual Invoice class. Because you are calling the Interface methods from the Invoice, you can be assured that changing a particular client class won't affect other clients.

>Thanks Bonnie. I'm still digesting all the responses. I'll post more questions as
>I get more confused :)
>
>
>
>>>Seems like a good use would be to create an interface whenever your class is designed
>>>to be subclassed.
>>
>>That would be overkill Kevin, and would soon be quite unwieldy and is quite unnecessary.
>>
>>As Kevin G said, you'll get used to it as you use it, but don't over-do it. Look carefully at the examples that several of us have provided for more insight as to *when* to use Interfaces.
>>
>>~~Bonnie
>>
>>
>>
>>
>>>
>>>
>>>>I'm starting to get it.
>>>>
>>>>OK, good. ;)
>>>>
>>>>Like I said, the more frequently you work with it, the more you'll get it.
>>>>
>>>>
>>>>When is it appropriate for me to design an interface for a class?
>>>>
>>>>You'll likely get 20 answers from 20 different people (with partial overlap)....let me answer this way...
>>>>
>>>>1) As an interface is essentially a "contract" (focuses on the "what", as opposed to the guts of the "how"), think of any sitation where you build the TERMS of a contract.
>>>>
>>>>2) You probably know that I develop a # of reporting apps. Most of the time I used stored procs to bring back data for the report. So the report and the proc will have input parameters (date range, user options, and selections) and then a result set (1 or more tables of resulting data). Obviously, if I define those 'terms' before I go build the actual proc and report, life will likely be a bit easier.
>>>>
>>>>Additionally, a well-defined interface means you've taken a step towards building some unit tests.
>>>>
>>>>Kevin