1

私のプロジェクトのコアライブラリには、非常に大きなクラスがあり、神オブジェクトになる傾向があります。その理由の1つは、ある期間にわたって、異なるモジュールにあるはずのタスクがこのクラスに入れられたことです。例-

class HugeClass{
    public void DoModuleXJob(){}
    public void DoModuleYJob(){}
}

不要なモジュール固有の動作をこのクラスからリファクタリングおよび移動する際の問題の1つは、モジュールXとモジュールYがコードを変更するのに多くの作業が必要になることです。回避策として、これらのメソッドを拡張メソッドに変換してから、関連するモジュールに移動することを考えていました。例-

// in module X
static class HugeClassExtensions{
    public static void DoModuleXJob(this HugeClass instance){}
} 

// in module Y
static class HugeClassExtensions{
    public static void DoModuleYJob(this HugeClass instance){}
}

モジュールYがDoModuleXJobを使用していない限り、これによってコンパイルの問題が発生することはありません。その逆も同様です。

これは良い解決策ですか？そのような場合にもっと良い方法はありますか？

4

4 に答える 4

1

これは、少なくとも機能を分割し、拡張機能「モジュール」間にメソッドの相互依存関係がないことを証明する方法を提供するため、悪い中間ステップではありません。これは、真のサブクラスを作成するための優れた最初のステップですが、それでも理想的ではありません（単体テストのためにモジュールクラスを個別にインスタンス化することはできません）。

このパーティションを作成すると、モジュールの境界をすでに特定しているため、新しいクラスを簡単に作成できるようになります。プロセスは次のようになります。

  1. 拡張メソッドに渡されたパラメーターは、コンストラクターで設定された新しいクラスのフィールドになります。

  2. すべての拡張メソッドが新しいクラスのメソッドになります。

  3. これで、メインクラスのインターフェイスを抽出できるようになったため、サブクラスは完全な実装に依存しなくなりました。場合によっては、機能を複数のインターフェイスに分割することで、依存関係をさらに減らすことができる場合があります。

  4. インターフェイスを介した依存関係の分離ができたので、個々のモジュールの単体テストを作成できます。

于 2010-10-14T18:29:17.013 に答える
0

拡張メソッドは単なる「シンタックスシュガー」です。一般的な静的メソッドを定義して、HugeClassインスタンスをそのパラメーターの1つにすることができます。ですから違いはありません。コンパイル後のCILファイルは同じになります。

于 2010-10-14T18:28:06.403 に答える
0

デザインが異なっているようですが、なぜWorkflowFoundation4.0を使用しなかったのですか。簡単で柔軟性があります。ワークフローでCodeActivityとしてコードを記述できます。コアに追加できる新しいモジュールジョブとしてワークフロー（アクティビティ）を想定できると思います。

さらに、非常に便利なワークフロー（アクティビティ）を動的に生成できます。

（私の悪い英語のためにすみません）

于 2010-10-14T18:59:48.430 に答える
0

本来あるべきデザインを作成し、HugeClassにある機能をあるべき場所に移動してから、メソッド呼び出しをHugeClassに残しますが、移動した場所まで機能を延期することをお勧めします。

class HugeClass
{
    [Obsolete("Use ModuleX.DoModuleXJob() instead", false)]
    public void DoModuleXJob() {
        ModuleX mod = new ModuleX();
        mod.DoModuleXJob();
    }
}
class ModuleX
{
    public void DoModuleXJob() {
    }
}

このようにして、時間の経過とともに、HugeClassでファサードパターンを採用しています。HugeClassメソッドに適用したObsolete属性は、HugeClassのメソッドを呼び出す何かがコンパイルされるたびに、新しい機能がどこにあるかを示す警告が生成されることを意味します。属性の「false」パラメータが警告になります。これをtrueに変更して、エラーにすることができます。このように、あなたは多くの余分な仕事をしていません、そしてそれはあなたがなりたいところへの進歩を表しています、それはあなたの拡張方法のテクニックが必ずしもそうするとは思わない。時間の経過とともに、HugeClassのメソッドは、それが空のクラスになり、それ自体が削除されるまで削除される可能性があります。

ちなみに、Martin Fowlerの本「リファクタリング」をまだ読んでいない場合は、優れた読み物です。その中で彼はこれと他の多くのテクニックについて論じています。

于 2010-10-14T19:35:42.860 に答える