7

私はかなり大きな製品に取り組んでいます。.Net 1.0はまだ開発中なので、品質の悪いコードがたくさんあり、単体テストを念頭に置いて作成されていないため、開発が続けられています。現在、品質を改善し、各機能のテストとバグ修正を実装しようとしています。私たちが今抱えている最大の問題の1つは、依存関係地獄と神オブジェクトです。特に悪い神オブジェクトが1つありますSession。基本的に、プログラムの現在のセッションに関連するものはすべてこのオブジェクトに含まれます。他にもいくつかの神オブジェクトがあります。

とにかく、Resharperを使用してそれらからインターフェースを抽出することにより、この神オブジェクトを「モック可能」にしました。ただし、これでもテストは困難です。ほとんどの場合、作成したコードを調べて、100の異なるメソッドとプロパティから実際にモックアウトする必要があるものを理解する必要があるためです。

このクラスへの参照は文字通り数千とは言わないまでも数百あるため、このクラスを分割するだけでは今のところ問題外です。

私はインターフェイスを持っているので（そしてほとんどすべてのコードがインターフェイスを使用するようにリファクタリングされています）、興味深いアイデアがありました。ISessionインターフェイスを他のインターフェイスから継承させた場合はどうなりますか。

たとえば、次のようなものがある場合：

interface IBar
{
  string Baz{get;set;}
}

interface IFoo
{
  string Biz{get;set;}
}

interface ISession: IFoo, IBar
{
}

このように、ISessionを使用する既存のコードを更新する必要はなく、実際の実装を更新する必要もありません。ただし、新しいコードでは、より詳細なIFooまたはIBarインターフェイスを使用してリファクタリングを記述しますが、ISessionを渡します。

そして最終的には、これにより、実際のISessionとSessiongodのインターフェイス/オブジェクトを最終的に分割するのが簡単になると思います。

今あなたに。これは、これらの神オブジェクトに対してテストし、最終的にそれらを分割するための良い方法ですか？これは文書化されたアプローチおよび/またはデザインパターンですか？このようなことをしたことがありますか？

4

1 に答える 1

6

私の立場からすると、これは適切で正しいアプローチです。後で、より具体的なサービスインスタンスをIFoo/IBarではなく/として挿入できますISession。これは、神クラスから多くの特定のサービスにクラスを抽出するためにさらにリファクタリングする前の、優れた中間ステップであると言えます。

私が見るいくつかのプロ：

第1段階：インターフェースの抽出

  • スーパー（神）クラス型はインターフェースによって抽象化されます
  • 単一機能の責任あるインターフェース（サービス）に依存しているため、コードの結合が少なくなります
  • 大規模なリファクタリングを行わずに、さらに進んで神クラスを多くのサービスに分割することができます。すべての人がすでにインターフェースAPIに依存しています。

第2段階：単一責任の原則を念頭に置いて、神クラスを多くの小さなサービスに分割します

第3段階：既存の単体テストを構造化して、テストを神クラスの周りにまとめるのではなく、サービスタイプごとにグループ化する

于 2013-02-08T15:26:19.627 に答える