Lazy or Sensible to leave empty legacy classes?

Question

We've had a slight change to our system which means what used to be two related business rule are now the exact same rule. Because of this, I've generalised the implementation and I'm wondering what to do with the old specified classes related to them.

Is it lazy to leave the old classes lying around and just inheriting the new generalised version (with no extra content, just empty classes)? Or is it sensible because it saves a good deal of refactoring?

The interface is the same regardless - so I'm curious : epically lazy, or cunningly avoiding unnecessary refactoring?

Answer 1

Get rid of the extra class. What's the purpose of keeping it?

Don't your refactoring tools handle this for you?

Answer 2

Get rid of it. That is the point of source control. If you ever need to refer to it, it'll be in the history.

Answer 3

If the code doesn't do anything, get rid of it. Source control will keep the history for you should you ever need to refer back to it.

Answer 4

Even if you don't have something like Resharper, you can use VS.NET's "Find Usages" tool. Then update all usages to the new class.

Alternatively, just delete it and fix the compile errors. A.k.s "poor man's refactoring".

Answer 5

imho, clean, readable and concise code should be ever developer's goal aside from meeting the business requirements. That said, I would deprecate the classes, and make a task to refactor when time allows. Deprecating the class will help developers to know what class should be used.

Answer 6

From pure OO design perspective, you should clean up the code.

From software delivery perspective, there are reasons why you may not want to do that:

• Minimize amount of unnecessary changes to the code. helps with investigations in production issues.

• Save the opportunity cost of re-factoring and use it on something more beneficial.