Prevent Massive Shadowing Of Methods [closed] - asp.net

Question

Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 3 years ago.
Improve this question
I'm in a project where it's pretty much my first time doing all the architecture myself, and I'm running into a frustrating situation. My architecture for forms seems to be correct from a heuristic perspective, but I don't think its implementation is correct.
My architecture is thus:
Base Class: OrderForm
Child Classes: PurchaseOrder, Invoice, Credit
Child Class of PurchaseOrder: StockingOrder
Architecturally this makes sense (to me) because all the child classes are OrderForms ("is a") and a Stocking Order "is a" Purchase Order, just a special kind.
PROBLEM
While coding my StockingOrder class, I've noticed that I've had to Shadow most if not all of the methods I want to use from PurchaseOrder since they conceptually do the same thing but require slightly different implementation functionality. This, of course, smells to me, but I don't know how to fix it. What am I doing wrong? Or is this normal?(!)
Thanks...

Answer 1

It sounds like you might need some virtual methods in PurchaseOrder. Maybe something like the following:
public abstract class OrderForm
{
//orderform members
}
public class PurchaseOrder: OrderForm
{
public void DoSomething()
{
//some logic that can be reused by child classes
DoSomethingElse();
}
protected virtual void DoSomethingElse()
{
//specialized logic
}
}
public class StockingOrder: PurchaseOrder
{
protected override void DoSomethingElse()
{
//specialized logic that makes StockingOrder different than PurchaseOrder
}
}
This should help to reuse more code as you could group the similar logic you are writing in the PurchaseOrder DoSomethingMethod while keepin the specialized logic (that is different between PurchaseOrder and StockingOrder) in your virtual DoSomethingElse method.

Answer 2

As mdearing06 suggested, you should use virtual methods (or just overridable methods) and override them.
Using Shadowing to change the functionality of your own code is somewhat of a bad practice. Shadowing is meant to be used in uncommon scenarios, i.e.: when you inherit from a class that was written by someone else and you must change some of its functionality, but can't view/edit the code itself.
Consider the fact that Shadowing is much like Overloading (only that it hides the base implementations), and quite different than Overriding.
The shadowing method will only be called if you explicitly refer to the object by its class; otherwise, the original method will be called (unlike Overriding, where the method is called based on the content - not on the representation - of the referenced object).
Here is an example of how representation affects a shadowed method's invokation:
Class BaseClass
Public Sub MyMethod()
Trace.WriteLine("The original method")
End Sub
End Class
Class ShadowClass
Inherits BaseClass
Shadows Sub MyMethod()
Trace.WriteLine("The shadowing method")
End Sub
End Class
Class Tester
Public Shared Sub TestClasses()
Dim myObj As Object = New ShadowClass
Dim var0 As BaseClass = myObj
var0.MyMethod()
Dim var1 As ShadowClass = myObj
var1.MyMethod()
End Sub
End Class
After running Tester.TestClasses, the trace will show: "The original method", followed by "The shadowing method".
Now, if we use the following code instead:
Class BaseClass
Public Overridable Sub MyMethod()
Trace.WriteLine("The original method")
End Sub
End Class
Class OverridingClass
Inherits BaseClass
Overrides Sub MyMethod()
Trace.WriteLine("The overriding method")
End Sub
End Class
Class Tester
Public Shared Sub TestClasses()
Dim myObj As Object = New OverridingClass
Dim var0 As BaseClass = myObj
var0.MyMethod()
Dim var1 As OverridingClass = myObj
var1.MyMethod()
End Sub
End Class
The Trace output will display "The overriding method", followed by "The overriding method".
To sum, I'd say that overriding is the "normal" way, and shadowing is an anomaly.

Answer 3

Another option is to use interfaces; set-up code contracts that allow you to program aganist a defined interface without having to worry about the impmentation underneath.
This also allows you to define multiple interfaces that focus on specific tasks, this allows your code to be much more maintainable and flexible.
Then, for common methods, put them in a helper class that your implementations can leverage off.
Check these out for more reference :)
http://www.developer.com/lang/other/article.php/939411/Implementing-Interfaces-in-VB-NET.htm
http://blogs.msdn.com/trobbins/archive/2004/08/26/221241.aspx