classes and interfaces

  • Thread starter Thread starter John
  • Start date Start date
J

John

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
 
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
Click to expand...

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).
 
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).
Click to expand...

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]
 
Inictus said:
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).
Click to expand...

Small correction, at least as I believe it to be (and I may be wrong).

An interface is not a type. The type would be the class. So to rephrase
what you stated:

.... The Car instance (myCar in your example) is considered to be of type
Car, which implements iCar. Car may inherit from another class (such as
Automobile), and continue this chain all the way up to the base class,
Object. ...

:) HTH,
Mythran
 
Small correction, at least as I believe it to be (and I may be wrong).

An interface is not a type.  The type would be the class.  So to rephrase
what you stated:

... The Car instance (myCar in your example) is considered to be of type
Car, which implements iCar.  Car may inherit from another class (such as
Automobile), and continue this chain all the way up to the base class,
Object. ...

:)  HTH,
Mythran- Hide quoted text -

- Show quoted text -
Click to expand...

The type class in the framework represents:

Classes
Value Types
Arrays
Interfaces
Pointers
Enumerations
Constructed generic types and generic type definitions


Hence i can write:

If TypeOf Car is ICar Then....
 
Back
Top