OK to assign an IDataObject reference to a DataObject variable

[**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.GetDa taObject()

'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.GetHashCo de (there is no IDataObject.Get HashCode) What
happens?

Thanks

[Nicholas Paldino [.NET/C# MVP]]

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 Paldino [.NET/C# MVP]
- mv*@spam.guard. caspershouse.co m

" **Developer**" <RE************ *@a-znet.com> wrote in message
news:ed******** ******@tk2msftn gp13.phx.gbl...

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.GetDa taObject()

'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.GetHashCo de (there is no IDataObject.Get HashCode) What
happens?

Thanks

[Andreas Mueller]

Nicholas Paldino [.NET/C# MVP] wrote:

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.

If you turn Option Strict On, your compiler will tell you about it :-)

--
To email me directly, please remove the *NO*SPAM* parts below:
*NO*SPAM*xmen40 @*NO*SPAM*gmx.n et

[Nicholas Paldino [.NET/C# MVP]]

Or, if you are using C#, the compiler will tell you about it as well. =)
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard. caspershouse.co m

"Andreas Mueller" <[e-mail] > wrote in message
news:41******** *****@individua l.net...

Nicholas Paldino [.NET/C# MVP] wrote:

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.

If you turn Option Strict On, your compiler will tell you about it :-)

--
To email me directly, please remove the *NO*SPAM* parts below:
*NO*SPAM*xmen40 @*NO*SPAM*gmx.n et

[**Developer**]

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 [.NET/C# MVP]" <mv*@spam.guard .caspershouse.c om> wrote in
message news:Oh******** ******@TK2MSFTN GP14.phx.gbl...

Or, if you are using C#, the compiler will tell you about it as well.
=)
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard. caspershouse.co m

"Andreas Mueller" <[e-mail] > wrote in message
news:41******** *****@individua l.net...

Nicholas Paldino [.NET/C# MVP] wrote:

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.

If you turn Option Strict On, your compiler will tell you about it :-)

--
To email me directly, please remove the *NO*SPAM* parts below:
*NO*SPAM*xmen40 @*NO*SPAM*gmx.n et

[Michael Bray]

" **Developer**" <RE************ *@a-znet.com> wrote in
news:Og******** ******@TK2MSFTN GP14.phx.gbl:

Or is it an instantiation of a class that implements the interface?

Exactly! :)

-mdb

[**Developer**]

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


"Michael Bray" <mbray@makeDInt oDot_ctiusaDcom > wrote in message
news:Xn******** *************** *****@207.46.24 8.16...

" **Developer**" <RE************ *@a-znet.com> wrote in
news:Og******** ******@TK2MSFTN GP14.phx.gbl:

Or is it an instantiation of a class that implements the interface?

Exactly! :)

-mdb

[Michael Bray]

" **Developer**" <RE************ *@a-znet.com> wrote in
news:uU******** ******@TK2MSFTN GP12.phx.gbl:

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

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 ArgumentExcepti on(...);
}
}

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