CODEWITHSUNDEEP
c++refactoring
lezebulon
lezebulon

Reputation: 7994

changing class hierarchy of legacy code

Are there any downsides to changing the class hierarchy of a class that has been in the software for a very long time (10+ years) and that is used extensively? I have a class A, that doesn't inherit from anything. What I'd like to do is make it inherit from a new abstract base class, and change 2 of its current methods to virtual methods. I would usually go for it but my coworkers are much more reluctants, so what possible problems could this cause? thanks

edit : the reason I want to do this:

We are creating a new module that can take as "source" either the old class A or the newly created class B. So I am thinking of creating an abstract class SourceofX who class A and B would inherit from. The "polymorphism" would only be used by new class / method that take a SourceofX object. If you have better ideas than this, I am all ears

Upvotes: 2

Views: 102

Answers (2)

Vaughn Cato
Vaughn Cato

Reputation: 64308

If you really think the new structure is better, then I would go with what Luchian Grigore says, but it isn't the only option. For example, you can use a proxy:

struct Base {
  virtual void doSomething() = 0;
};

void someFunction(Base &base)
{
  ...
  base.doSomething();
  ...
}

struct NewClass : Base {
  virtual void doSomething();
};

struct OldClassProxy : Base {
  OldClassProxy(OldClass &old) : old(old) { }

  virtual void doSomething()
  {
    old.doSomething();
  }

  OldClass &old;
};

Now you can use your new function with instances of your old class without having to modify the old class:

NewClass a;
OldClass b;
someFunction(a);
OldClassProxy b_proxy(b);
someFunction(b_proxy);

If there are lots of places where you need the proxy, then you can write an overload:

void someFunction(OldClass &old_class)
{
  OldClassProxy proxy(old_class);
  someFunction(proxy);
}

which will let you do this:

NewClass a;
OldClass b;
someFunction(a);
someFunction(b);

Upvotes: 2

Luchian Grigore
Luchian Grigore

Reputation: 258608

There are always risks when changing legacy code. Most of which you can't foresee.

Most often, the causes are "hacky" bug fixes done by others and organically becoming part of the soft. Now that it's stable, those hacky fixes probably introduced some other bugs and led to some other hacky fixes that fixed those bugs. The software is 10 years old, so I guarantee such fixes exist.

I personally take very much caution in even the smallest change in old code. Introducing a new level of inheritance is not a small code change. So yes, it's very risky.

A high-level analysis would only point out design issues, but you are left with issues that would only arise from testing. If that particular piece of code has an owner, go ask him. Then, ask him again. Bug him and don't stop until you find something.

My suggestion is to write unit tests (if you don't already have them, in which case - perfect) that test the s&%t out of that class, children... well, everything.

After that, write some more unit tests. Run the tests multiple times. On multiple platforms. At night. On Wednesdays.

Upvotes: 2

Related Questions