views:

34

answers:

3

I was modifying an overridden method of a subclass. In order to determine the impact of the change, I went through all possible scenarios and tested them.

The problem is, the "all possible scenarios" are determined by reading business use cases, putting break point to find out when this particular overridden method is being hit instead of others.

Is there a reliable or programmatic way to find out about impacts? For example, if it is not an overridden method, I can simply "Find All Instance" or even using grep to find where it is getting called. Is there a similar measure for overridden methods? Or is it just an inconvenience of polymorphism?

A: 

A quick suggestion would be to rename the function. The compiler will let you know quickly about what needs to be looked at and possibly refactored. Obviously this entirely depends upon you being in control of all possible client code.

csharptest.net
Well, it is an overridden method, compiler will not complain and just use the base class implementation.
Bill Yang
Yes, I ment you could rename the method by changing it in the base class. It's the only sure-fire wau I know that forces you to visit all possible uses. It's not fun but it gets it done.
csharptest.net
The problem with this is, depends on how many other subclasses inherit the base class and override this method, it will go from inconvenient to impossible. And is not much different than using "Find all references" or similar features.
Bill Yang
+1  A: 

There may be scientific approaches to this topic. But in general you will likely have to go with the "just an inconvenience of polymorphism".

I know there are people how outright oppose any OO for this very reason. In fact this was also the reason why in .Net methods are, unlike in Java, by default NOT overridable.

If you search on google for polymorphism breaks encapsulation or inheritance breaks encapsulation you will find lots of discussions on that topic.

Foxfire
+1  A: 

I don't know all the details so it's hard to speculate, but what impact do you expect the change to have?

So long as you aren't changing the method's signature, just verify the behavior of the class in isolation. This is a key principle of unit testing. Since you mention breakpoints, I'm assuming that you're testing manually in the debugger. Unit testing can get you away from all that; it's worth looking into.

If the method modifies global state or if the class is tightly coupled to other classes, testing in isolation may be difficult. See Adding unit tests to legacy code.

As another option, ReSharper has a Find Usages feature that can find callers of a method and optionally callers of the base class. There's also an option to find overriding methods under Find Usages Advanced.

TrueWill
Unfortunately, it is modifying global state (some cache data). But your link to the other question is interesting, thanks!
Bill Yang