、、、などのCommonDaoOperationsいくつかのジェネリック メソッドを含むユーティリティ クラスを作成しています。一部の DAO はより複雑で、これらのジェネリック メソッドを使用できないため、これは基本クラスではありませんが、多くの DAO は使用できます。CreateUpdateDelete
私は今、そのユーティリティクラスが正確にどのように見えるべきかを考えています:
- 静的ジェネリック メソッドのみを持つ静的クラス
- プライベートな読み取り専用メンバーとして DAO ごとに 1 回作成される、ジェネリック メソッドを持つ通常のクラス
- DAO メソッドごとに 1 回 (各呼び出しで) 作成される、ジェネリック メソッドを持つ通常のクラス
DAO/メソッドごとにクラスのインスタンスを作成すると、明らかに静的メソッドを呼び出すよりもコストがかかりますが、これらのコストはほとんどすべてのアプリケーションで無視できると確信しています。
非静的クラスの利点があるため、ソリューション2または3を好みます（インターフェイス、モック可能、派生/拡張可能、必要に応じて将来コンストラクターを介してパラメーターを収集できます（10パラメーターと比較して）メソッド)))。
したがって、本当の問題は、ユーティリティ クラスをメンバー変数として作成する必要があるのか、それとも DAO メソッドごとにインスタンス化する必要があるのかということです。
public void Create(User user) {
new CommonDaoOperations().Create(user);
}
public void Delete(User user) {
var daoOps = new CommonDaoOperations();
daoOps.CheckSomething(); // just an example of multiple calls to the class
daoOps.Delete(user);
}
他の開発者がこれらのアプローチのいずれかについてどう考えているか、またはこれを行うための別の/より良い方法がまだあるかどうかに興味があります.
編集
アプローチ＃3をもっと考えるべきだったことに気付きました-Vadimが指摘したように、各メソッドでインスタンス化されたときに具象クラスを置き換えるのは面倒ですが、プロパティでそれを考慮することができます：
private CommonDaoOperations DaoOps {
get { return new CommonDaoOperations(); }
}
public void Create(User user) {
DaoOps.Create(user);
}
これは上記のスニペットよりも保守しやすいと思いますが、DAO に「ユーティリティ」クラスのプロパティを導入したことを知っています。これは、それ自体がコードの匂いである可能性があります (Ant P が指摘したように)。
概要
これは難しい決断でした。私は Ant P からの回答を受け入れましたが、Vadim の回答も正当です。どのアプローチを使用するかは、ユーティリティ クラスによって異なります。3 つのアプローチすべてに用途があります(更新された #3 を除く)。少なくとも、それは提供された回答に対する私の見解です。
- 静的クラスには用途がありますが、上で簡単に説明したように多くの欠点もあります。
- メソッドごとにインスタンス化された通常のクラス:ユーティリティ クラスが作成され、必要な場所でのみ使用されます。依存関係を減らし、型を純粋に保ちます。
- メンバーとしてインスタンス化された通常のクラス:多くの/すべてのメソッドがユーティリティ クラスのインスタンスを必要とする場合、メンバー変数を作成することをお勧めします。このようにして、タイプまたはインスタンス化の方法を変更するのが簡単になります。