2011-09-01 23 views
27

私はユーティリティクラスDateUtilを持っているとしましょう(下記参照)。このメソッドを使用するには、 呼び出し元メソッドはDateUtils.getDateAsString(aDate)を使用します。 静的修飾子を削除してDateUtilをSpring Bean(DateUtilsBeanを参照)にして呼び出しクラス に挿入するか、それをそのままにしておく方が良いでしょうか?私は、静的な使用して見ることができますSpringアプリケーションのユーティリティクラス - 静的メソッドを使用する必要がありますか?

一つの欠点は、モックの周りの問題ですが、私はそうは思わないHow to mock with static methods?

public class DateUtils { 

    public static String getDateAsString(Date date) {  
     String retValue = "" // do something here using date parameter 
     return retValue; 
    } 
} 

春豆のバージョン

@Component 
public class DateUtilsBean { 

    public String getDateAsString(Date date) {  
     String retValue = "" // do something here using date parameter 
     return retValue; 
    } 
} 

答えて

21

を参照してください。 DateUtilsクラスは、副作用がなく入力パラメータだけを処理する純粋なユーティリティクラスのように聞こえます。この種の機能は、静的な方法で残っている可能性もあります。私はあなたが日付ヘルパーメソッドを模擬したいと思う可能性が高いとは思わない。

+6

_anything_ _could_がSpring Beanとして配線されているからといってSpring Beanとして配線する必要はありません。 –

+2

静的メソッドがアプリケーションを駆動する構成ファイルを読み込むとどうなりますか?それは私がその行動を模擬したいと思う可能性が高いです。あなたは機能テストをしたいと思っていますが、あなたは "設定工場"になりたくありません。もしそれがシングルトンであれば、私はそのメソッドをもっと模擬して、コードからテストを動かすことができます。 しかし、PowerMockでは静的メソッドをモックすることも可能です。 – uthomas

+4

これはオーバーエンジニアリングかもしれませんが、注入可能なBeanにすることで、依存クラスの単体テストが容易になります。インターフェイスを実装していればテストするのがさらに簡単になります。 – Behrang

4

SpringのライフサイクルがSpringによって管理され、最終的に依存性を注入し、オブジェクトをプールし、適切な方法でテストすることができるため、Spring Beanとして宣言する方が良いでしょう。通常のオブジェクトとして使用し、パラメータとして渡したり、サブクラスなどでメソッドを再定義したりすることができます。

要するに、ほとんどの場合、より良い設計になるでしょう。それにもかかわらず、露出したような単純なケースでは、大きな違いはありません。

4

私はSean Patrick Floydに同意します。

クラスのメソッドが外部依存関係(データベース、ファイルシステム、ユーザー設定、その他のオブジェクト/ Beanなど)を使用せずに受け取ったパラメータだけを処理する場合は、それは静的メソッドで、通常はプライベートコンストラクタを持つ最終クラスにあります。

それ以外の場合は、Spring Beanを使用して実装します。

したがって、この基準に従って、私が静的メソッドを持つクラスを作成するとします。

よろしくお願いいたします。

関連する問題