3

私の職場では、現在、静的クラスに対する十字軍が存在しているようです。私はその一部を理解することができます、彼らはモジュール性をテストするユニット全体を壊すようなものです。ただし、静的クラスの削除を要求するコードレビューの流入が見られます。

一般的なケースは、コンパイル時に「既知」である他のいくつかのオブジェクトが春に注入されるユーティリティクラスです。他のメンバー変数はありません。クラスMがこの静的クラスを呼び出している場合、このユーティリティクラスを非静的にして、クラスMに注入するという提案が常に表示されます。

これは私には意味がありません。時間の無駄に見え、ユーティリティクラスが使いにくくなること以外は特に問題はありません。私が知る限り、正当化は通常単体テストのためですが、テストパラダイムに準拠するために有効なコードを変更する必要があるという考えは好きではありません。確かに、単純な静的ユーティリティクラスをモックするのはおそらくやり過ぎでしょう。

このユースケースでは静的クラスが適切ですか、それとも回避するのが最善ですか？

4

6 に答える 6

2

2つのアプローチの違いは小さいと思いますが、クラスに状態が含まれていない限り、静的にする方が少し良いでしょう。クラスAにこのコードがあるとしましょう：

StaticClass.utilMethod()

このコードをクラスBIで使用する場合は、コピーして貼り付けることができます。それでおしまい。メンバー変数の追加、インジェクションなどはありません。cmd-ccmd-v。

既存のコードが静的クラスを使用し、それを変更すると作業が必要になることを考えると、静的クラスを引き続き使用するのが間違いなく最善です。

于 2012-08-10T18:58:40.300 に答える
1

確かに、単純な静的ユーティリティクラスをモックするのはおそらくやり過ぎでしょう。

あなたはこれについて絶対に正しいです。静的クラスは、そのようなクラスをモックする利点がない、非常に単純なユーティリティクラスにのみ使用する必要があります。他の目的で使用している場合は、デザインを再考する必要があります。

そのクラスに状態が含まれていない場合、非静的クラスを使用することは合理的ですか？

これは実際には状態とは何の関係もありません。たとえば、戦略オブジェクトには状態が含まれていないことがよくありますが、静的ではありません。それらは通常、共通のインターフェースを実装し、交換可能/モック可能である必要があります。

于 2012-08-11T23:12:30.883 に答える
1

私は静的クラスの使用に投票します...つまり、純粋にユーティリティの目的で静的メソッドのみを使用するクラスです。java.util.CollectionsJavaでさえ、次のようなクラスを提供してくれました。java.util.Arrays

于 2012-08-10T18:55:06.037 に答える
1

静的クラスが自分のものではない、たとえば.NET Frameworkの一部であると一瞬ふりをすると、チームはそれをどのように処理しますか？彼らの答えは私の答えでしょう。言い換えれば、その質問に対する彼らの答えが彼らがあなたに求めていることと矛盾している場合、彼らはおそらく.NET静的クラスでの動作方法またはあなたの静的クラスでの動作方法を変更する必要があります。

于 2012-08-10T18:59:51.830 に答える
1

私は静的クラスの使用を避け（実際に静的メソッドを含むクラスについて話していると仮定します）、テストのしやすさのために使用します。

静的メソッドを使用している場合、単体テストに静的メソッドを使用するコードの部分をモック/スタブするのは困難です。

このことを考慮：

public String myMethod() {
    String complicatedStringOutput = MyUtility.createComplicatedStringOutput();
    //do some more complicated work on this String
}

このメソッドの単体テストを作成するには、作成をテストする必要なしに、どのようにして「真の単体テスト」にするのcomplicatedStringOutputでしょうか。私の単体テストでは、単体テストの焦点となる方法のみをテストすることを好みます。

これに変更します：

public String myMethod(MyNonStaticUtility util) {
    String complicatedStringOutput = util.createComplicatedStringOutput();
    //do some more complicated work on this String
}

突然、このクラスは「真の単体テスト」を書くのがはるかに簡単になります。MyNonStaticUtilityスタブまたはモックを使用して、の動作を制御できます。

とはいえ、それは本当にあなた（またはあなたのビジネスユニット）次第です。単体テストを重視し、複雑なコードを適切にテストカバレッジすることが重要であると感じた場合は、これが推奨されるアプローチです。コードの「修正」に投資する時間/お金がない場合、それは起こりません。

于 2012-08-10T19:05:21.527 に答える
1

当然、依存します。

  • 静的クラスを使用するコードをどのようにテストしますか？
  • 静的クラスは、頻繁にモックする必要がある動作をカプセル化しますか？
  • 誰かがそれらの静的クラスの動作を変更する必要がありますか？

ついに：

  • Springが管理するシングルトンBeanを注入しないという説得力のある理由はありますか？
于 2012-08-10T19:10:25.570 に答える