Re: classes and interfaces
- From: rowe_newsgroups <rowe_email@xxxxxxxxx>
- Date: Mon, 24 Mar 2008 10:10:15 -0700 (PDT)
On Mar 24, 11:35 am, Inictus <Stormgu...@xxxxxxxxxxx> wrote:
On Mar 24, 6:53 am, "John" <johndev...@xxxxxxxxxxx> wrote:
Hi,
I've wrote a small class called Car and attached an interface iCar. So far,
so good....
What i would like to know is ... What is the correct use for the
interface...?
sub Drive(myCar as iCar){
}
... Works great....
However...
Dim myCar as new iCar
doesn't work....
Kind regards
John
As Seth demonstrated, you still instantiate your object the normal way
- i.e. using the constructor of the Car class.
Just remember that an interface is a contract of sorts. If you
implement an interface on a class, you are guarenteeing that this
class implements the properties and methods of the interface. You
cannot instantiate an object from an interface directly.
So, when your car class implements the iCar interface, you are saying
that your car class implements those properties and methods defined on
the iCar interface. The Car instance (myCar in your example) is
considered to be of type iCar (as well as type Car, as well as type
object and as well as any other classes that you have inherited from).
So you can pass the instance of myCar to a sub that takes parameters
of type: Car, iCar and Object (or if you have inherited from another
class).
In the sub Drive you have defined, remember that when you pass your
myCar instance to it, you will only have access to the properties and
methods defined on the iCar interface (because sub Drive takes an
object of type iCar). Any other properties and methods you have
defined on the Car class beyond those specified on the iCar interface
you will not have access to (unless you do a type conversion - but
then you risk the possibility of an exception being thrown if you pass
an object not of the type you are converting to).
For people reading this thread and wondering what the benefits of
using an interface is, then here you go.
Suppose you want to be able to handle multiple forms of automobiles,
and all of them need to have certain properties and methods (number of
passengers, drive, etc) but each have different implemantions. You do
not want the ability to tell them apart, as you might not know the
exact classes, say if you load the types from an external dll at
runtime. With an interface you can force those properties and methods
and be able to handle any type at runtime, regardless of "true" type.
For example.
//////////
Public Interface IAutomobile
Property Passengers As Integer
Sub Drive()
End Interface
//////////
You can use that interface in a generic method to do anything to any
automobile.
////////////
Public Sub DriveAnAutomobile(automobile As IAutomobile)
If automobile.Passengers > 0 Then
automobile.Drive()
End If
End Sub
////////////
This comes in handy as you can have multiple types of automobiles use
that method, regardless of whether the assembly with the
'DriveAnAutomobile' knows about the specific types.
////////////
Public Sub Main()
Dim car As IAutomobile = New Car()
Dim truck As New Truck() '// Assume Truck implements IAutomobile
DriveAnAutomobile(car)
DriveAnAutomobile(truck)
End Sub
////////////
Thanks,
Seth Rowe [MVP]
.
- References:
- classes and interfaces
- From: John
- Re: classes and interfaces
- From: Inictus
- classes and interfaces
- Prev by Date: WTF is a 'Unicode (UTF-8)' fallback?!
- Next by Date: Re: Accessing public property on multiple instances of open forms
- Previous by thread: Re: classes and interfaces
- Next by thread: Re: classes and interfaces
- Index(es):
Relevant Pages
|
