2

ソフトウェアに非常に長い間 (10 年以上) 存在し、広く使用されているクラスのクラス階層を変更することの欠点はありますか? 私は、class A何からも継承しない を持っています。私がやりたいのは、新しい抽象基本クラスから継承し、現在のメソッドの 2 つを仮想メソッドに変更することです。私は通常それを選びますが、同僚はもっと気が進まないので、これによりどのような問題が発生する可能性がありますか? ありがとう

編集：私がこれをしたい理由：

古いクラスAまたは新しく作成されたクラスBのいずれかを「ソース」として使用できる新しいモジュールを作成しています。そのため、クラスAとBが継承する抽象クラスSourceofXを作成することを考えています。「ポリモーフィズム」は、SourceofX オブジェクトを取る新しいクラス/メソッドによってのみ使用されます。これよりも優れたアイデアがある場合は、私はすべて耳にします

4

2 に答える 2

2

新しい構造の方が優れていると本当に思うなら、ルキアン・グリゴーレの言うとおりにしますが、それが唯一の選択肢ではありません。たとえば、プロキシを使用できます。

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;
};

これで、古いクラスを変更することなく、古いクラスのインスタンスで新しい関数を使用できます。

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

プロキシが必要な場所がたくさんある場合は、オーバーロードを記述できます。

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

これにより、これが可能になります：

NewClass a;
OldClass b;
someFunction(a);
someFunction(b);
于 2012-09-27T14:32:09.120 に答える
2

レガシ コードの変更には常にリスクが伴います。そのほとんどは予測できません。

ほとんどの場合、その原因は他の人が行った「ハッキーな」バグ修正であり、有機的にソフトの一部になっています。安定したので、これらのハッキーな修正はおそらく他のバグを導入し、それらのバグを修正する他のハッキーな修正につながりました. ソフトウェアは 10 年前のものなので、そのような修正が存在することを保証します。

個人的には、古いコードのわずかな変更にも細心の注意を払っています。新しいレベルの継承の導入は、小さなコード変更ではありません。そうです、それは非常に危険です。

高レベルの分析では設計上の問題のみが指摘されますが、テストからのみ発生する問題が残ります。そのコードの特定の部分に所有者がいる場合は、彼に尋ねてください。それから、もう一度彼に聞いてください。彼を悩ませて、何かを見つけるまで止まらないでください。

私の提案は、そのクラス、子供たち...まあ、すべてをテストする単体テストを作成することです（まだ持っていない場合は、その場合は完璧です）。

その後、さらにいくつかの単体テストを作成します。テストを複数回実行します。複数のプラットフォームで。夜に。水曜日に。

于 2012-09-27T14:15:23.413 に答える