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