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" <ma**********@hotmail.com> wrote in message
news:Oh****************@TK2MSFTNGP14.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]" <Ja************@msn.com> wrote in message
| news:Oy****************@TK2MSFTNGP10.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.Dispose method Close as its more logical to Close a
| file
| > rather then Dispose it.
| >
| > If the IDisposable.Dispose 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(Object),
| > offering type safe versions PersonCollection.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.Draw
| >
| > 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.Draw 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.Draw
| >
| > End Function
| >
| > End Class
| >
| > Which avoids ambiguity in the public interface of Circle.
| >
| > Hope this helps
| > Jay
| >
| >
| > "masoud bayan" <ma**********@hotmail.com> wrote in message
| > news:uO**************@TK2MSFTNGP14.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.DifferentDraw()
| > |
| > | End Sub
| > |
| > | End Class
| > |
| > |
| > |
| > | Thanks
| > |
| > | Masoud
| > |
| > |
| > |
| > |
| >
| >
|
|
