OK to assign an IDataObject reference to a DataObject variable

  • Thread starter Thread starter **Developer**
  • Start date Start date
D

**Developer**

Although the code is VB I believe the question is OOP
I tried the VB NG but no answer.
I suspect the c# programmer is more apt to be aware of these kinds of
subtleties so I', trying here.

I do the following:

Note that I'm returning and interface because GetDatObject returns an
interface.

Also note that DataObject implements IDataObject
====

Public Shared Function GetContents() As DataObject

Dim ClipboardDataO As IDataObject = Clipboard.GetDataObject()

'assign an IDataObject reference to a DataObject variable

Return ClipboardDataO

End Function

End Class

elsewhere I do

Dim DataO As DataObject = GetContents()

That is I store the reference to the returned interface into an object of
class DataObject (not IDataObject)

It appears to work OK but now I noticed what I did and wonder why it is OK
to assign an IDataObject reference to a DataObject variable

Could you add some understanding the above?

Suppose I use DataO.GetHashCode (there is no IDataObject.GetHashCode) What
happens?

Thanks
 
The reason it works is because the call to GetDataObject on Clipboard
*happens* to return a DataObject, which implements IDataObject.

However, this is bad practice. If the method returns IDataObject, then
it could theoretically return ANY type that implements that interface, and
it would be right to do so.

So, in your case, don't work with DataObject, work with the interface
implementation instead.

Hope this helps.
 
Nicholas said:
The reason it works is because the call to GetDataObject on Clipboard
*happens* to return a DataObject, which implements IDataObject.

However, this is bad practice. If the method returns IDataObject, then
it could theoretically return ANY type that implements that interface, and
it would be right to do so.

So, in your case, don't work with DataObject, work with the interface
implementation instead.

Hope this helps.
Click to expand...
If you turn Option Strict On, your compiler will tell you about it :-)
 
Or, if you are using C#, the compiler will tell you about it as well. =)
 
It returns an IDataObject not a DataObject.
I say that because that is what I've read.
But what is an IDataObject?
An interface is basically a class without any code.
If an IDataObject is an instantiation of an interface, what is it?
Or is it an instantiation of a class that implements the interface?


Thanks



Nicholas Paldino said:
Or, if you are using C#, the compiler will tell you about it as well.
=)
Click to expand...
 
It's confusing (to me) because the doc says GetDataObject returns an
IDataObject.
The doc also says IDatObject is an interface.

Somehow, that doesn't sound the same as saying it is an object that
implements an interface.

Thanks
 
Somehow, that doesn't sound the same as saying it is an object that
implements an interface.
Click to expand...

Keep in mind that any particular interface might be implemented by more
than one class. The point of what they are saying is that you should
NOT assume exactly which class it is that the function is returning. As
long as you only access the methods that are defined on the interface,
everything will be fine.

Its not so different from returning an object as one of the classes it
derives from... so for example,

public abstract class Vehicle { }
public class Car : Vehicle { }
public class Limo : Car { }
public class Bus : Vehicle { }

public class VehicleMaker
{
public static Vehicle MakeVehicle(int type)
{
if (type == 0) return new Car();
else if (type == 1) return new Limo();
else if (type == 2) return new Bus();
}
}

This is valid because Car, Limo, and Bus are all derived from Vehicle.
Now if you replace abstract class Vehicle with interface IVehicle, like
this:

public interface IVehicle { }
public class Car : IVehicle { }
public class Limo : Car { }
public class Bus : IVehicle { }

public class VehicleMaker
{
public static IVehicle MakeVehicle(int type)
{
if (type == 0) return new Car();
else if (type == 1) return new Limo();
else if (type == 2) return new Bus();
else throw new ArgumentException(...);
}
}

then nothing really has changed, except here the function is returning
an interface IVehicle instead of a class Vehicle. The result is the
same - you don't know (without checking types or whatnot) whether the
Vehicle/IVehicle that is returned is a Car, Bus, or Limo. But you know
for sure that any functions specified by the Vehicle abstract class or
the IVehicle interface will work on the object that MakeVehicle returns.

So really, when a function returns an "interface", what it is saying is
that it is returning an object that implements that interface, but its
not going to tell you which one.

-mdb
 
Back
Top