interface odd behavior

**Chris Dunaway** · Nov 21 '05, 06:07 PM

Re: interface odd behavior

I think you need to cast obj2 to IShape in order to directly access the
interface members:

DirectCast(obj2 ,IShape).Draw()

**masoud bayan** · Nov 21 '05, 06:07 PM

Re: interface odd behavior

"Chris Dunaway" <dunawayc@gmail .com> wrote in message
news:1118240610 .342044.79160@g 49g2000cwa.goog legroups.com...[color=blue]
> I think you need to cast obj2 to IShape in order to directly access the
> interface members:
>
> DirectCast(obj2 ,IShape).Draw()
>[/color]

It is not a *have to* to cast a derived class to its base in hierarchy to
use base defined methods.

Think of ToString method of class Object, shall every class has a cast for
that?

Actually it is polymorphic behavior of OO languages that let us use a
derived class and access with the base methods.

**Irfan** · Nov 21 '05, 06:08 PM

Re: interface odd behavior

hi, Masud

When you actually do
obj2.DifferentD raw()
You are calling the IShape 's Draw method but implemented by you in Ccircle
class.
It will be of no use to call Interface methods, because they themselves are
empty anyway.

HTH
Irfan

"masoud bayan" <masoud_bayan@h otmail.com> wrote in message
news:uObJ$IDbFH A.2128@TK2MSFTN GP14.phx.gbl...[color=blue]
> I've come across something in Interface implementation that I am not sure
> is
> correct behavior in VB.NET (and maybe C#) or not?
>
>
>
> Consider following example:
>
>
>
> Public Interface IShape
>
> Sub Draw()
>
> End Interface
>
>
>
> Public Class CCircle
>
> Implements IShape
>
> Public Sub DifferentDraw() Implements IShape.Draw
>
> End Sub
>
> End Class
>
>
>
> According to OOP rules any CCircle object *IS-A* IShape object and also
> IShape interface is a *CONTRACT* that guarantees all of its objects
> implement methods in this contract. But in the following test, obj2 which
> is
> supposed to obey above rules does not have access to Interface Draw()
> method!!!???
>
>
>
> Public Class Test
>
> Public Sub Test()
>
> Dim obj1 As IShape
>
> obj1 = New CCircle
>
> obj1.Draw()
>
>
>
> Dim obj2 As CCircle
>
> obj2 = New CCircle
>
> obj2.DifferentD raw()
>
> End Sub
>
> End Class
>
>
>
> Thanks
>
> Masoud
>
>
>
>[/color]

**Cor Ligthert** · Nov 21 '05, 06:08 PM

Re: interface odd behavior

Masoud,

[color=blue]
> Think of ToString method of class Object, shall every class has a cast for
> that?
>[/color]
The ToString() method is a member of Object. Object is not an interface
however the base class from which every class inherits.

Cor

**masoud bayan** · Nov 21 '05, 06:08 PM

Re: interface odd behavior

Ok.

I agree that ToString is defined in base class but what does it mean that
Interface is a Contract the guarantees every object derived from that
Interface implement s the methods in that contract?

Think someone defined IShape and then created a method as:

Public Sub(obj as IShape)

obj.draw()

End Sub

This method according to the test that I sent is not working anymore!!

Regarding "Tostring is method with implementation in base class", I think as
..net (and modern OOP languages) does not support multiple inheritance we
have interfaces but it does not mean inheritance and polymorphic behavior
should change. If we define an abstract method in an abstract class shall we
cast derived objects to base to be able to access the name of method?

Masoud

"Irfan" <irfan@asc-ltd.co.uk> wrote in message
news:u%23yWsfDb FHA.3184@TK2MSF TNGP15.phx.gbl. ..[color=blue]
> hi, Masud
>
> When you actually do
> obj2.DifferentD raw()
> You are calling the IShape 's Draw method but implemented by you in[/color]
Ccircle[color=blue]
> class.
> It will be of no use to call Interface methods, because they themselves[/color]
are[color=blue]
> empty anyway.
>
> HTH
> Irfan
>
>
>
> "masoud bayan" <masoud_bayan@h otmail.com> wrote in message
> news:uObJ$IDbFH A.2128@TK2MSFTN GP14.phx.gbl...[color=green]
> > I've come across something in Interface implementation that I am not[/color][/color]
sure[color=blue][color=green]
> > is
> > correct behavior in VB.NET (and maybe C#) or not?
> >
> >
> >
> > Consider following example:
> >
> >
> >
> > Public Interface IShape
> >
> > Sub Draw()
> >
> > End Interface
> >
> >
> >
> > Public Class CCircle
> >
> > Implements IShape
> >
> > Public Sub DifferentDraw() Implements IShape.Draw
> >
> > End Sub
> >
> > End Class
> >
> >
> >
> > According to OOP rules any CCircle object *IS-A* IShape object and also
> > IShape interface is a *CONTRACT* that guarantees all of its objects
> > implement methods in this contract. But in the following test, obj2[/color][/color]
which[color=blue][color=green]
> > is
> > supposed to obey above rules does not have access to Interface Draw()
> > method!!!???
> >
> >
> >
> > Public Class Test
> >
> > Public Sub Test()
> >
> > Dim obj1 As IShape
> >
> > obj1 = New CCircle
> >
> > obj1.Draw()
> >
> >
> >
> > Dim obj2 As CCircle
> >
> > obj2 = New CCircle
> >
> > obj2.DifferentD raw()
> >
> > End Sub
> >
> > End Class
> >
> >
> >
> > Thanks
> >
> > Masoud
> >
> >
> >
> >[/color]
>
>[/color]

**Armin Zingler** · Nov 21 '05, 06:08 PM

Re: interface odd behavior

"masoud bayan" <masoud_bayan@h otmail.com> schrieb[color=blue]
> I've come across something in Interface implementation that I am not
> sure is correct behavior in VB.NET (and maybe C#) or not?
>
>
>
> Consider following example:
>
>
>
> Public Interface IShape
>
> Sub Draw()
>
> End Interface
>
>
>
> Public Class CCircle
>
> Implements IShape
>
> Public Sub DifferentDraw() Implements IShape.Draw
>
> End Sub
>
> End Class
>
>
>
> According to OOP rules any CCircle object *IS-A* IShape object and
> also IShape interface is a *CONTRACT* that guarantees all of its
> objects implement methods in this contract. But in the following
> test, obj2 which is supposed to obey above rules does not have access
> to Interface Draw() method!!!???[/color]

obj2 is not declared as IShape. You are using a different contract. The
contract name now is "CCircle" - that's how the variable is declare - and a
CCircle does have a DifferentDraw method. It does not have a Draw method
because it's not part of the contract.

[color=blue]
> Public Class Test
>
> Public Sub Test()
>
> Dim obj1 As IShape
>
> obj1 = New CCircle
>
> obj1.Draw()
>
>
>
> Dim obj2 As CCircle
>
> obj2 = New CCircle
>
> obj2.DifferentD raw()
>
> End Sub
>
> End Class[/color]

Armin

**Jay B. Harlow [MVP - Outlook]** · Nov 21 '05, 06:08 PM

Re: interface odd behavior

masoud,
In addition to the other comments.

C# partially supports this with Explicit Interface Implementation.

http://msdn.microsoft.com/library/de...pec_13_4_1.asp

I find the VB.NET to be stronger here, as I can rename the method and/or
change the visibility of the method. C# only allows you to hide the method.

| According to OOP rules any CCircle object *IS-A* IShape object and also
| IShape interface is a *CONTRACT* that guarantees all of its objects
| implement methods in this contract. But in the following test, obj2 which
is
| supposed to obey above rules does not have access to Interface Draw()
| method!!!???
Circle implements all the methods of IShape! however it simply renamed
and/or hide one or more of its methods. As you show, when an instance of a
Circle object is in an IShape variable or parameter you can access all of
IShape's methods.

Consider IDisposable. For some classes, such as Files, it makes more sense
to name IDisposable.Dis pose method Close as its more logical to Close a file
rather then Dispose it.

If the IDisposable.Dis pose method was required to be called Dispose it might
add confusion to other programmers using your class, especially if the class
offers both Dispose & Close.

Also consider IList, when defining a type safe list (such as CollectionBase)
its desired to hide most of the IList members, such as IList.Add(Objec t),
offering type safe versions PersonCollectio n.Add(Person) instead.

Consider:

Public Interface IShape
Sub Draw()
End Interface

Public Interface IDeckOfCards
Function Draw() As Card
End Interface

If you attempt to implement both interfaces, such as:

Public Class CCircle
Implements IShape
Implements IDeckOfCards

Public Sub Draw() Implements IShape.Draw
End Sub

Public Function Draw() As Card Implements IDeckOfCards.Dr aw

End Function

End Class

Without renaming, the above won't compile, as Draw is both a function & a
Sub. Further they do different things. IShape.Draw paints the shape on the
screen, while IDeckOfCards.Dr aw returns a card.

With renaming you can do:

Public Class CCircle
Implements IShape
Implements IDeckOfCards

Public Sub DrawShape() Implements IShape.Draw
End Sub

Public Function DrawCard() As Card Implements IDeckOfCards.Dr aw

End Function

End Class

Which avoids ambiguity in the public interface of Circle.

Hope this helps
Jay

"masoud bayan" <masoud_bayan@h otmail.com> wrote in message
news:uObJ$IDbFH A.2128@TK2MSFTN GP14.phx.gbl...
| I've come across something in Interface implementation that I am not sure
is
| correct behavior in VB.NET (and maybe C#) or not?
|
|
|
| Consider following example:
|
|
|
| Public Interface IShape
|
| Sub Draw()
|
| End Interface
|
|
|
| Public Class CCircle
|
| Implements IShape
|
| Public Sub DifferentDraw() Implements IShape.Draw
|
| End Sub
|
| End Class
|
|
|
| According to OOP rules any CCircle object *IS-A* IShape object and also
| IShape interface is a *CONTRACT* that guarantees all of its objects
| implement methods in this contract. But in the following test, obj2 which
is
| supposed to obey above rules does not have access to Interface Draw()
| method!!!???
|
|
|
| Public Class Test
|
| Public Sub Test()
|
| Dim obj1 As IShape
|
| obj1 = New CCircle
|
| obj1.Draw()
|
|
|
| Dim obj2 As CCircle
|
| obj2 = New CCircle
|
| obj2.DifferentD raw()
|
| End Sub
|
| End Class
|
|
|
| Thanks
|
| Masoud
|
|
|
|

**Phill. W** · Nov 21 '05, 06:08 PM

Re: interface odd behavior

"Irfan" <irfan@asc-ltd.co.uk> wrote in message
news:u%23yWsfDb FHA.3184@TK2MSF TNGP15.phx.gbl. ..[color=blue]
> When you actually do
> obj2.DifferentD raw()
> you are calling the IShape's Draw method[/color]

*Not* true. obj2 is defined as a CCircle and, therefore, can
only access the methods, etc. defined by CCircle.
To use methods defined via the IShape Interface, you must cast
the object to the Interface Type, as in

DirectCast( obj2, IShape ).Draw()

or, better,

Dim obj2 as IShape
obj2.Draw()
[color=blue]
> It will be of no use to call Interface methods, because they
> themselves are empty anyway.[/color]

/If/ I understand this statement correctly (apologies if not) then
you've missed something fundamental about Interfaces.

The Interface /defines/ the methods, etc. that a class must
provide implementations for in order to be used as an "instance"
of the Interface. The Interface methods are not "empty" as you
describe; the actual code "behind" them is provided (somewhere)
in every Class that implements the Interface.

Regards,
Phill W.

**masoud bayan** · Nov 21 '05, 06:08 PM

Re: interface odd behavior

Thanks Jay, was great information.

Also thanks all others for their comments.

Just the last question:

There is only one problem though if someone defines an IShape interface with
Draw method and then a function as for feature objects of IShape:

Sub Test(obj as IShape)

Obj.Draw

End Sub

There is no guarantee that this function will work in future as maybe
somebody change Draw to something else in feature, except he explicitly cast
obj to Ishape in code.

So shall whenever we want to use an object in .net hierarchy and call a
method that we assume should be available in object (because of an interface
in hierarchy) first cast it to interface?

Masoud

"Jay B. Harlow [MVP - Outlook]" <Jay_Harlow_MVP @msn.com> wrote in message
news:Oy4rK%23Db FHA.3848@TK2MSF TNGP10.phx.gbl. ..[color=blue]
> masoud,
> In addition to the other comments.
>
> C# partially supports this with Explicit Interface Implementation.
>
>[/color]
http://msdn.microsoft.com/library/de...pec_13_4_1.asp[color=blue]
>
> I find the VB.NET to be stronger here, as I can rename the method and/or
> change the visibility of the method. C# only allows you to hide the[/color]
method.[color=blue]
>
> | According to OOP rules any CCircle object *IS-A* IShape object and also
> | IShape interface is a *CONTRACT* that guarantees all of its objects
> | implement methods in this contract. But in the following test, obj2[/color]
which[color=blue]
> is
> | supposed to obey above rules does not have access to Interface Draw()
> | method!!!???
> Circle implements all the methods of IShape! however it simply renamed
> and/or hide one or more of its methods. As you show, when an instance of a
> Circle object is in an IShape variable or parameter you can access all of
> IShape's methods.
>
> Consider IDisposable. For some classes, such as Files, it makes more sense
> to name IDisposable.Dis pose method Close as its more logical to Close a[/color]
file[color=blue]
> rather then Dispose it.
>
> If the IDisposable.Dis pose method was required to be called Dispose it[/color]
might[color=blue]
> add confusion to other programmers using your class, especially if the[/color]
class[color=blue]
> offers both Dispose & Close.
>
> Also consider IList, when defining a type safe list (such as[/color]
CollectionBase)[color=blue]
> its desired to hide most of the IList members, such as IList.Add(Objec t),
> offering type safe versions PersonCollectio n.Add(Person) instead.
>
> Consider:
>
> Public Interface IShape
> Sub Draw()
> End Interface
>
> Public Interface IDeckOfCards
> Function Draw() As Card
> End Interface
>
> If you attempt to implement both interfaces, such as:
>
> Public Class CCircle
> Implements IShape
> Implements IDeckOfCards
>
> Public Sub Draw() Implements IShape.Draw
> End Sub
>
> Public Function Draw() As Card Implements IDeckOfCards.Dr aw
>
> End Function
>
> End Class
>
> Without renaming, the above won't compile, as Draw is both a function & a
> Sub. Further they do different things. IShape.Draw paints the shape on the
> screen, while IDeckOfCards.Dr aw returns a card.
>
> With renaming you can do:
>
> Public Class CCircle
> Implements IShape
> Implements IDeckOfCards
>
> Public Sub DrawShape() Implements IShape.Draw
> End Sub
>
> Public Function DrawCard() As Card Implements IDeckOfCards.Dr aw
>
> End Function
>
> End Class
>
> Which avoids ambiguity in the public interface of Circle.
>
> Hope this helps
> Jay
>
>
> "masoud bayan" <masoud_bayan@h otmail.com> wrote in message
> news:uObJ$IDbFH A.2128@TK2MSFTN GP14.phx.gbl...
> | I've come across something in Interface implementation that I am not[/color]
sure[color=blue]
> is
> | correct behavior in VB.NET (and maybe C#) or not?
> |
> |
> |
> | Consider following example:
> |
> |
> |
> | Public Interface IShape
> |
> | Sub Draw()
> |
> | End Interface
> |
> |
> |
> | Public Class CCircle
> |
> | Implements IShape
> |
> | Public Sub DifferentDraw() Implements IShape.Draw
> |
> | End Sub
> |
> | End Class
> |
> |
> |
> | According to OOP rules any CCircle object *IS-A* IShape object and also
> | IShape interface is a *CONTRACT* that guarantees all of its objects
> | implement methods in this contract. But in the following test, obj2[/color]
which[color=blue]
> is
> | supposed to obey above rules does not have access to Interface Draw()
> | method!!!???
> |
> |
> |
> | Public Class Test
> |
> | Public Sub Test()
> |
> | Dim obj1 As IShape
> |
> | obj1 = New CCircle
> |
> | obj1.Draw()
> |
> |
> |
> | Dim obj2 As CCircle
> |
> | obj2 = New CCircle
> |
> | obj2.DifferentD raw()
> |
> | End Sub
> |
> | End Class
> |
> |
> |
> | Thanks
> |
> | Masoud
> |
> |
> |
> |
>
>[/color]

**Jay B. Harlow [MVP - Outlook]** · Nov 21 '05, 06:08 PM

Re: interface odd behavior

masoud,
| There is only one problem though if someone defines an IShape interface
with
| Draw method and then a function as for feature objects of IShape:
I don't see a problem...

| Sub Test(obj as IShape)
|
| Obj.Draw
|
| End Sub

| There is no guarantee that this function will work in future as maybe
| somebody change Draw to something else in feature, except he explicitly
cast
| obj to Ishape in code.
Yes there is a "guarantee" . The "Implements IShape.Draw" on the Sub's
declaration is the "guarantee" .

| > Public Sub Draw() Implements IShape.Draw
| > End Sub

When you pass the Circle object to the IShape parameter, the Test function
will call the method labeled with "Implements IShape.Draw", independent of
what you named the method itself in Circle...

C# does not use the "Implements IShape.Draw" syntax, which is why the method
in C# either needs to be public or it needs to use the Explicit Interface
Implementation syntax. I find the "Implements IShape.Draw" syntax to be far
more flexible.

Hope this helps
Jay

"masoud bayan" <masoud_bayan@h otmail.com> wrote in message
news:OhDH%23UEb FHA.3196@TK2MSF TNGP14.phx.gbl. ..
| Thanks Jay, was great information.
|
| Also thanks all others for their comments.
|
|
|
| Just the last question:
|
| There is only one problem though if someone defines an IShape interface
with
| Draw method and then a function as for feature objects of IShape:
|
| Sub Test(obj as IShape)
|
| Obj.Draw
|
| End Sub
|
|
|
| There is no guarantee that this function will work in future as maybe
| somebody change Draw to something else in feature, except he explicitly
cast
| obj to Ishape in code.
|
| So shall whenever we want to use an object in .net hierarchy and call a
| method that we assume should be available in object (because of an
interface
| in hierarchy) first cast it to interface?
|
|
|
| Masoud
|
|
|
|
| "Jay B. Harlow [MVP - Outlook]" <Jay_Harlow_MVP @msn.com> wrote in message
| news:Oy4rK%23Db FHA.3848@TK2MSF TNGP10.phx.gbl. ..
| > masoud,
| > In addition to the other comments.
| >
| > C# partially supports this with Explicit Interface Implementation.
| >
| >
|
http://msdn.microsoft.com/library/de...pec_13_4_1.asp
| >
| > I find the VB.NET to be stronger here, as I can rename the method and/or
| > change the visibility of the method. C# only allows you to hide the
| method.
| >
| > | According to OOP rules any CCircle object *IS-A* IShape object and
also
| > | IShape interface is a *CONTRACT* that guarantees all of its objects
| > | implement methods in this contract. But in the following test, obj2
| which
| > is
| > | supposed to obey above rules does not have access to Interface Draw()
| > | method!!!???
| > Circle implements all the methods of IShape! however it simply renamed
| > and/or hide one or more of its methods. As you show, when an instance of
a
| > Circle object is in an IShape variable or parameter you can access all
of
| > IShape's methods.
| >
| > Consider IDisposable. For some classes, such as Files, it makes more
sense
| > to name IDisposable.Dis pose method Close as its more logical to Close a
| file
| > rather then Dispose it.
| >
| > If the IDisposable.Dis pose method was required to be called Dispose it
| might
| > add confusion to other programmers using your class, especially if the
| class
| > offers both Dispose & Close.
| >
| > Also consider IList, when defining a type safe list (such as
| CollectionBase)
| > its desired to hide most of the IList members, such as
IList.Add(Objec t),
| > offering type safe versions PersonCollectio n.Add(Person) instead.
| >
| > Consider:
| >
| > Public Interface IShape
| > Sub Draw()
| > End Interface
| >
| > Public Interface IDeckOfCards
| > Function Draw() As Card
| > End Interface
| >
| > If you attempt to implement both interfaces, such as:
| >
| > Public Class CCircle
| > Implements IShape
| > Implements IDeckOfCards
| >
| > Public Sub Draw() Implements IShape.Draw
| > End Sub
| >
| > Public Function Draw() As Card Implements IDeckOfCards.Dr aw
| >
| > End Function
| >
| > End Class
| >
| > Without renaming, the above won't compile, as Draw is both a function &
a
| > Sub. Further they do different things. IShape.Draw paints the shape on
the
| > screen, while IDeckOfCards.Dr aw returns a card.
| >
| > With renaming you can do:
| >
| > Public Class CCircle
| > Implements IShape
| > Implements IDeckOfCards
| >
| > Public Sub DrawShape() Implements IShape.Draw
| > End Sub
| >
| > Public Function DrawCard() As Card Implements IDeckOfCards.Dr aw
| >
| > End Function
| >
| > End Class
| >
| > Which avoids ambiguity in the public interface of Circle.
| >
| > Hope this helps
| > Jay
| >
| >
| > "masoud bayan" <masoud_bayan@h otmail.com> wrote in message
| > news:uObJ$IDbFH A.2128@TK2MSFTN GP14.phx.gbl...
| > | I've come across something in Interface implementation that I am not
| sure
| > is
| > | correct behavior in VB.NET (and maybe C#) or not?
| > |
| > |
| > |
| > | Consider following example:
| > |
| > |
| > |
| > | Public Interface IShape
| > |
| > | Sub Draw()
| > |
| > | End Interface
| > |
| > |
| > |
| > | Public Class CCircle
| > |
| > | Implements IShape
| > |
| > | Public Sub DifferentDraw() Implements IShape.Draw
| > |
| > | End Sub
| > |
| > | End Class
| > |
| > |
| > |
| > | According to OOP rules any CCircle object *IS-A* IShape object and
also
| > | IShape interface is a *CONTRACT* that guarantees all of its objects
| > | implement methods in this contract. But in the following test, obj2
| which
| > is
| > | supposed to obey above rules does not have access to Interface Draw()
| > | method!!!???
| > |
| > |
| > |
| > | Public Class Test
| > |
| > | Public Sub Test()
| > |
| > | Dim obj1 As IShape
| > |
| > | obj1 = New CCircle
| > |
| > | obj1.Draw()
| > |
| > |
| > |
| > | Dim obj2 As CCircle
| > |
| > | obj2 = New CCircle
| > |
| > | obj2.DifferentD raw()
| > |
| > | End Sub
| > |
| > | End Class
| > |
| > |
| > |
| > | Thanks
| > |
| > | Masoud
| > |
| > |
| > |
| > |
| >
| >
|
|

**Herfried K. Wagner [MVP]** · Nov 21 '05, 06:08 PM

Re: interface odd behavior

"masoud bayan" <masoud_bayan@h otmail.com> schrieb:[color=blue]
> There is only one problem though if someone defines an IShape interface
> with
> Draw method and then a function as for feature objects of IShape:
>
> Sub Test(obj as IShape)
>
> Obj.Draw
>
> End Sub
>
>
>
> There is no guarantee that this function will work in future as maybe
> somebody change Draw to something else in feature, except he explicitly
> cast
> obj to Ishape in code.[/color]

The type of the 'obj' parameter is already 'IShape', thus no cast is
necessary.

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>

**masoud bayan** · Nov 21 '05, 06:08 PM

Re: interface odd behavior

Thanks for all replies.

Masoud

"Herfried K. Wagner [MVP]" <hirf-spam-me-here@gmx.at> wrote in message
news:eNZODgEbFH A.1404@TK2MSFTN GP09.phx.gbl...[color=blue]
> "masoud bayan" <masoud_bayan@h otmail.com> schrieb:[color=green]
> > There is only one problem though if someone defines an IShape interface
> > with
> > Draw method and then a function as for feature objects of IShape:
> >
> > Sub Test(obj as IShape)
> >
> > Obj.Draw
> >
> > End Sub
> >
> >
> >
> > There is no guarantee that this function will work in future as maybe
> > somebody change Draw to something else in feature, except he explicitly
> > cast
> > obj to Ishape in code.[/color]
>
> The type of the 'obj' parameter is already 'IShape', thus no cast is
> necessary.
>
> --
> M S Herfried K. Wagner
> M V P <URL:http://dotnet.mvps.org/>
> V B <URL:http://classicvb.org/petition/>
>[/color]

interface odd behavior

interface odd behavior

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment