Problem solveGet help with specific problems with your technologies, process and projects.

Polymorphism can lead to head scratching in VB.NET

This tip explains a rather nasty pitfall that can happen when you use polymorphism in VB.NET and how to avoid it.

Share this item with your network:

By

Eric Mutta

Published: 06 Oct 2003

This tip was submitted to the VS.NET Info Center by member Rick Spiewak. Please let other users know how useful it is by rating it below. Do you have a tip or code of your own you'd like to share? Submit it here.

Many VB developers have probably heard the statement: "VB6 does support full object oriented programming, so it's not a 'real' language." Now with VB7 (VB.NET), OOP is here in all its glory. Well, it's here, but it sure isn't all glory -- at least not when it comes to polymorphism. In this tip, I will show a rather nasty pitfall that can happen when you use polymorphism in VB.NET.

The code below is very simple, very naive. However, it could take several hours of head scratching to figure out what's wrong. Before you paste it into a new console application project, try and figure out why the stack overflow occurs without using the debugger to trace through the execution path.

This is not something I discovered by accident. I actually designed it by making use of my understanding of polymorphism. The problem is, it can happen without you knowing in your everyday coding work, whether you like it or not.

So why does the stack oveflow occur?

*Parent.p2() calls Parent.p1()
*Parent.p1() is polymorphic because it can be overriden
*Child.p1() overrides Parent.p1() so any calls to Parent.p1() will actually
call Child.p1() if you have an instance of class Child.
*Child.p1() calls MyBase.p2()
*MyBase.p2() is actually Parent.p2()

Now if you are still with me, the pitfall comes when you have an instance of class Child and call procedures p1 and p2. Calling p1 produces the following execution flow:

Child.p1 -> Parent.p2 -> Child.p1 -> Parent.p2 -> Child.p1 -> etc.

and the cycle repeats until we have no stack space left. Calling p2 produces the following execution flow:

The writer of Parent.p2 would probably expect his or her p1() call to go to Parent.p1(), which it does, if we have an instance of Parent. The oversight comes in either completely forgetting that the call is polymorphic, or assuming that p1() in child classes will work like the one in Parent.

The writer of Child.p1() would have no idea that Parent.p2() calls Parent.p1(). As a result, he or she would have no clue that calling MyBase.p2() would lead to a polymorphic call back into Child.p1() and start a cycle (this is what causes the stack overflow).

The overflows would not occur if polymorphism wasn't used -- i.e. Parent.p1() was not overridable.

The problem is further compounded by the fact that the polymorphic calls don't stand out and look different to non-polymorphic calls, which makes it harder to realise that the problem is caused by a polymorphic call.

Now for the tip:

If you are designing a class, use polymorphism only if absolutely necessary. Also, don't depend on the behavior of your polymorphic methods, because that behaviour WILL change, when child classes override your class, and lead to things like this pitfall.

If you are inheriting from a class, override only the methods that you need to override.

If you have code for the parent class, try and find a method that is (a) called from your child class, (b) defined in the parent class you are inheriting from, and (c) calls a method that you have overriden. If you can find such a method, then this pitfall WILL occur sooner or later in your code.

The full glory of OOP is now in VB.NET, but so are the nightmares. So be careful, and happy coding!

Start the conversation

0 comments

Register

I agree to TechTarget’s Terms of Use, Privacy Policy, and the transfer of my information to the United States for processing to provide me with relevant information as described in our Privacy Policy.

Please check the box if you want to proceed.

I agree to my information being processed by TechTarget and its Partners to contact me via phone, email, or other means regarding information relevant to my professional interests. I may unsubscribe at any time.