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.
Module MyModule
Class Parent
Public Overridable Sub p1()
Console.Write("Parent.p1")
End Sub
Public Sub p2()
'blah blah
p1()
'blah blah
End Sub
End Class
Class Child
Inherits Parent
Public Overrides Sub p1()
Console.Write("Child.p1")
MyBase.p2()
End Sub
End Class
Sub Main()
Dim p As Parent
Dim c As Child
p = New Parent()
p.p1() 'OK
p.p2() 'OK
p = New Child()
p.p1() 'stack overflow
p.p2() 'stack overflow
c = New Child()
c.p1() 'stack overflow
c.p2() 'stack overflow
End Sub
End Module
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:
Child.p2 -> Child.p1 -> Parent.p2 -> Child.p1 -> Parent.p2 -> Child.p1 -> etc.
If you are lost (which is perfectly human given the complexity of the pitfall), then the best way to understand it is to step through the code when the following lines in Sub Main execute:
p = New Parent()
p.p1() 'OK
p.p2() 'OK
p = New Child()
p.p1() 'stack overflow
p.p2() 'stack overflow
c = New Child()
c.p1() 'stack overflow
c.p2() 'stack overflow
Some things to note:
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!
