Please let other users know how useful this tip is by rating it below. Do you have a tip or code of your own you'd like to share? Submit it here.
A couple of months ago, I submitted the tip Polymorphism can lead to head scratching in VB.NET, in which I showed how inheritance-based polymorphic behavior could lead to a hard-to-debug pitfall.
Another developer submitted the tip Polymorphism is a must in VB.NET, in which he demonstrated a "solution" to the problem. In his tip, he proposed the use of the "MyClass" keyword to eliminate the circular calls. (Please look at the code in both tips for reference -- for brevity, I won't repeat it here.)
May I point out that the other developer's solution "solves" the problem by actually GETTING RID of polymorphism (the use of MyClass.p1 from the Parent.p2 subroutine always calls Parent.p1, even though p1 was marked as Overridable -- effectively disabling the polymorphic behaviour of Parent.p1 just as if it was marked as NotOverridable). This defeats the whole purpose of inheritance-based polymorphism and doesn't really solve the problem, because now the behavior of the code has been changed and the result won't be the same.
To the best of my knowledge (and I am open to correction), there is no way to solve this problem and STILL keep the inheritance-based polymorphic behavior. (Delegate-based polymorphism and interface-based polymorphism may provide alternatives though I have not explored them.) Like with all programming pitfalls, careful coding and redesign is the only way out.
OOP is a powerful paradigm, but it (like pretty much everything else in the world) is not without its problems (see this article and other articles on that site for examples). I don't think it "...should be practiced at ALL times within .NET development..." (added emphasis) as the other
developer states. This is especially true since VB.NET is a multi-paradigm language supporting both POP (procedure oriented programming) and OOP (object oriented programming). If this was C#, Java or Eiffel, then you have no option but to use OOP. But in VB.NET, use the most appropriate paradigm for the solution (which is usually a mixture of both POP and OOP).
To close, I thank the other develooper for providing food for thought. To conclude: use OOP where its appropriate, but (like the other author said) "...with careful planning and design in order not to lose focus."
Happy holidays and happy coding!
