when to use an Interface (the template like thing) in my project?

27 Oct 2006 5:09 PM

Rich

Hello,

my project (vb2005) contains several classes that each produce lists of data
which get stored/displayed in ado.net tables that have the same structure for
each of the lists produced by each class. Class1 produces 3 lists which get
stored in 3 ado.net tables (each table has a different structure). Class2
produces 3 similar lists that get stored in the same 3 ado.net tables.
Class3...class8 also produce 3 lists per class that get stored in the same 3
ado.net tables. Each class contains the same sub which takes the same args,
but the sql to produce the lists is different for each class. The lists are
similar in structure but way different in content.

Right now I select a class based on selections from a from. If optionbtn1
is checked I produce my lists using class1, optionbtn2 ... class2...

If Option1.Checked.Equals(true) then
cls = new class1
ElseIf Option2.Checked.Equals(true) then
cls = new class2
....
cls.RunSub(arg1, arg2)
....

I have used an interface thing once before to be able to loop through a
collection of classes. I looped through the interface. In the scenario
above would there be any use for an interface? If yes, what do I gain by
using an Interface thing

And what is the correct expression/name for the Interface thing I am talking
about? I don't like referring to it as a Thing. Is it an object? a class?

Thanks,
Rich

27 Oct 2006 6:37 PM

GÃ¶ran Andersson

An interface is like a contract. It can contain defintions for
properties and methods, but it can't contain any code or data. If a
class inherits an interface, it has to implement what the interface
specifies.

An interface works pretty much like an abstract base class that only
contains abstract properties and abstract methods, only a class can
inherit as many interfaces as it wants, but only inherit from one base
class.

Interfaces are usually used to specify capabilites of a class, like a
class that inherits IList can be used as a list.

Usually the type of a reference is a class, but you can also use an
interface as type. That means that the reference can be used for any
object that inherits the interface, and you can use any properties or
methods that the interface specify without caring what the actual class
of the object is.

Rich wrote:
Show quoteHide quote

> Hello,
>
> my project (vb2005) contains several classes that each produce lists of data
> which get stored/displayed in ado.net tables that have the same structure for
> each of the lists produced by each class. Class1 produces 3 lists which get
> stored in 3 ado.net tables (each table has a different structure). Class2
> produces 3 similar lists that get stored in the same 3 ado.net tables.
> Class3...class8 also produce 3 lists per class that get stored in the same 3
> ado.net tables. Each class contains the same sub which takes the same args,
> but the sql to produce the lists is different for each class. The lists are
> similar in structure but way different in content.
>
> Right now I select a class based on selections from a from. If optionbtn1
> is checked I produce my lists using class1, optionbtn2 ... class2...
>
> If Option1.Checked.Equals(true) then
> cls = new class1
> ElseIf Option2.Checked.Equals(true) then
> cls = new class2
> ...
> cls.RunSub(arg1, arg2)
> ...
>
> I have used an interface thing once before to be able to loop through a
> collection of classes. I looped through the interface. In the scenario
> above would there be any use for an interface? If yes, what do I gain by
> using an Interface thing
>
> And what is the correct expression/name for the Interface thing I am talking
> about? I don't like referring to it as a Thing. Is it an object? a class?
>
> Thanks,
> Rich