vb.net: Option Strict and late binding problem -- vb.net

Re: Option Strict and late binding problem

Samuel R. Neff
2/1/2005 12:22:16 PM

The IClonable.Clone() example shown earlier is exactly what you need,
but if you can't see how calling Clone() actually calls Copy() through
explicit interface implementation then you can create your own
interface and use it as follows

Interface ICopiable
Function Copy() As Object
End Interface

Class Foo
Implements ICopiable

Function Copy() Implements ICopiable.Copy
...
End Function
End Class

Class Bar
Implements ICopiable

Function Copy() Implements ICopiable.Copy
...
End Function
End Class

Sub Test()
Dim al As New ArrayList
al.Add(new Foo)
al.Add(new Bar)

For Each obj as ICopiable in al
Dim newObj = obj.Copy()
Next
End Sub

Of course since all the Copy methods you mentioned already implement
IClonable.Clone, then calling Clone is the exact same thing, but if
using a custom ICopiable interface is somehow cleaner or more
understandable, then use that. But don't knock .NET's OOD techniques
when you don't understand how to use them.

Best regards,

Sam

[quoted text, click to view]

Re: Option Strict and late binding problem

Phill. W
2/1/2005 12:28:36 PM

[quoted text, click to view]

"Object" isn't half as useful as you might think - always try to get at
a proper type when manipulating objects and, since both (all?) of
your classes implement IClonable, that's as good a type as any when
you need to use them, as in :

For Each objekt As IClonable In myArrayListInstance
objcopy = objekt.Clone() ' returns either Foo or Bar
' build another ArrayList with copies
NewArrayList.Add( objekt )
Next

HTH,
Phill W.

Re: Option Strict and late binding problem

Daniel Klein
2/1/2005 12:37:24 PM

Mttias,

Thank you for the cortesy of your reply.

Unfortunately, this won't work. Each of the Copy() methods is doing a bit
more than what Object.Clone() is doing, which is the reason for creating my
own implementation. And each of the Copy() methods cannot be refactored to
a common implementation.

Besides, this problem address a more generic one of how to achieve true
polymorphism without late binding.

Any other ideas are welcome.

Daniel Klein
Cuyahoga Falls, OH

On Tue, 01 Feb 2005 01:46:03 +0100, Mattias Sjögren
[quoted text, click to view]

Re: Option Strict and late binding problem

Daniel Klein
2/1/2005 1:43:04 PM

On Tue, 1 Feb 2005 12:28:36 -0000, "Phill. W"
[quoted text, click to view]

Good answer Phil, and it would work if all I was using was the Clone()
method, but the Copy() method in each class is doing more than just
'cloning'.

It looks like this is one place where 'late binding' will have to do.

Re: Option Strict and late binding problem

Mattias Sjögren
2/1/2005 3:59:19 PM

Daniel,

[quoted text, click to view]

As long as the Copy method Implements ICloneable.Clone, the same
method is called. So the same work is done.

[quoted text, click to view]

Interface implementation or deriving from a common base class with
virtual methods are great ways of accomplishing that.

Mattias

--
Mattias Sjögren [MVP] mattias @ mvps.org
http://www.msjogren.net/dotnet/ | http://www.dotnetinterop.com

Re: Option Strict and late binding problem

Daniel Klein
2/1/2005 5:03:53 PM

[quoted text, click to view]

Sorry, but no...at least not in this manner :-(

I thought the purpose of polymorphism was to eliminate cumbersome if/then
logic. Besides, there are more classes that implement the Copy() method,
which means the if/then logic would have to be modifed every time a new
class was created that implements the Copy() method. This goes against the
grain of OOD techniques.

I still maintain that late binding is the only solution to 'pure'
polymorphic behavior such as this.

Daniel Klein

Re: Option Strict and late binding problem

Samuel R. Neff
2/2/2005 10:21:51 AM

The thing is, ICloneable.Clone() and Copy() are the exact same method.
When you declare

Function Copy() As Object Implements ICloneable.Clone

Then you can execute this method via

obj.Copy()

or

DirectCast(obj, ICloneable).Clone()

And it calls the exact same method. This is called explicit interface
implementation where you're implementing an interface method but
internally using a different method name. This way when the object is
declared as the type that defined it, "Clone" is not accessible, but
"Copy" is. But you can cast it to ICloneable and then "Clone" is
accessible. But no matter what you do, it calls the exact same code,
the contents of the function.

Sam

On Wed, 02 Feb 2005 15:13:18 GMT, Daniel Klein
[quoted text, click to view]

Re: Option Strict and late binding problem

Daniel Klein
2/2/2005 3:13:18 PM

IClonaeable.Clone() will never work in this instance due the the 'extra
work' the Copy() methods have to do. However the ICopiable solution has
possibilities, I'll let you know. Thanks.

What I was 'knocking' was the if/then logic, not .NET. Apology accepted ;-)

Dan

On Tue, 01 Feb 2005 12:22:16 -0500, Samuel R. Neff
[quoted text, click to view]

Re: Option Strict and late binding problem

Daniel Klein
2/14/2005 4:08:30 PM

Just to put some closure on this, the piece I was missing was to do:

For Each objekt As ICloneable In myArrayList

It was the 'As ICloneable' that was missing.

Thanks Samuel, I has been educational to say the least.

Daniel Klein

On Wed, 02 Feb 2005 10:21:51 -0500, Samuel R. Neff
[quoted text, click to view]

Got something to say? Click here to post a reply to this thread.

Don't see what you're looking for? Try a search.

View other messages in the vb.net group.