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.
While we both agree that object-oriented design and practice must be implemented "...with careful planning and design in order not to lose focus." I dont agree with his sentence (and I am wide-open to any corrections or citicisms.) about the MyClass keyword "...getting rid of polymorphism" in my earlier codes.
Exists: When several classes, which each implement the operation, either have a common superclass in which the operation exists, or else implement an same common interface that contains the operation.
In this case, as long as you can override the p1 method of the parent or base class, that method itself is polymorphic. As long as I can override or extend that method, without changing the method name of the class, polymorphism has taken place.
I admit I was wrong not to stress on the fact that the error lies on the code-design issue as pointed out in the most recent tip on this subject,The polymorphism debate, part 2, and not a language handicap of VB.NET itself.
We have to stress to young, budding, junior and even senior code builders, warriors, writers, authors that the quality of code itself lies in the code design, and not the language itself.
By the above token, what I am trying to say is that OOP is just a feature (albeit a BIG feature) of a language, it doesnt necessarily mean that just because a language has OOP, any application or logic that is written in that particular language will have flawless codes.
I am not a VB.NET Ppoponent ... I am a technology evangelist. I have worked with Java programmers that churned out low-quality-designed Java codes and I have also worked with legacy Basic and COBOL programmers that churned out good-quality codes. What is defined by quality, to me, is the maintainability of it.
Please refer to this excellent Code Project article here about the wrong use of OOP.
Taking a good look at Eric's first code base that was meant for demonstrative purpose, it is already poorly designed (please correct me if I am wrong) when:
You design a base class that has methods (p2) calling an overridable method (p1) without defining whether the overridable p1 you are calling in p2 acutally belongs to the Base class or the Subclass p1. That is already a NO-NO in OOAD.
However, Eric has already given the antidote and the preventive measures to take when designing in his intial article.
The "MyClass" keyword of VB.NET is just a solution to the demonstrated codes that Eric had presented in that context. It is not meant to solve the problem of Circular Reference in OOP. But in all fairness, no keyword can.
My tip, Polymorphism is a must in VB.NET, only serves as another preventive measure to be added on top of Eric's and to solve a similar problem should such a situation arises. You add the "MyClass" keyword to signify to the calling class that all references to p2 must call the Parent Class's method p1.
Polymorphism still exists because you are allowing the Subclass to override or /and extend its methods. What you do within the overriden code shouldn't signify if that method is polymorphic or not ... i.e., if I didn't call MyBase.p2 in p1 of Child Class, does it mean that suddenly the Base Class p1 is now polymorphic?
I thank Eric for his very constructive comments and his thoughts and more importantly, making us think, create and innovate. I think we both agree that just because we have plutonium on our backyard doesnt mean we should go create a nuclear bomb. It should all done very carefully and with proper design or we end up nuking ourselves via a stack overflow in the process. :)
