列挙型と . を渡すためにコンストラクターをオーバーロードしたフォームがありList<int>
ます。
今、私は別のものも渡す必要があることに気付きましたint
(それは に属しませんList<int>
)。
どの時点で、これらすべてのパラメーターをクラスに再グループ化およびリファクタリングし、カプセル化して渡すことが「良い形式」(しゃれは意図されていません) と見なされますか?
それとももっと良い方法がありますか (Houdini 風の巧妙な手先を必要としません)?
列挙型と . を渡すためにコンストラクターをオーバーロードしたフォームがありList<int>
ます。
今、私は別のものも渡す必要があることに気付きましたint
(それは に属しませんList<int>
)。
どの時点で、これらすべてのパラメーターをクラスに再グループ化およびリファクタリングし、カプセル化して渡すことが「良い形式」(しゃれは意図されていません) と見なされますか?
それとももっと良い方法がありますか (Houdini 風の巧妙な手先を必要としません)?
フィールドをパブリック プロパティとして公開し、次の構文を使用できます。
var myinstance = new MyType
{
Prop1 = val1,
Prop2 = val2,
Prop3 = val3
};
これにより、コンストラクターを何度も変更する必要がなくなります。私はあなたの「いつ...にするのが最善か」という質問に関して、私はそれが2つまたは3つを超えて成長すると予想される場合(現在または将来)、パラメータークラスを作成します。ただし、これはかなりの議論の余地があるかもしれません!
この関数用に新しいオブジェクトを作成して作成する前に考慮すべきこと
この機能をどのくらいの頻度で使用していますか? 重複したコードはありませんか? このクラスを作成すると、重複したコードを削除できますか? 効率 (コードのパフォーマンスとメンテナンス) は向上しますか? どちらが速いですか?顧客はこれについてあまり気にしません。
より多くのパラメーターを使用して別のコンストラクターを追加しても、慣習に反することはありませんが、奇妙な順序で自分自身を呼び出すコンストラクターが大量にある場合は、再考することをお勧めします...
アプリケーションで必要な場合は、追加してください。持つ:
public FormConstructor(List<int> someInts, MyEnumThing anEnumYay, int anotherInt)
悪くない - 私のネーミングを除いて....
私の意見?クラスを作成することによる潜在的な利点が見られない場合は、Int を追加します。
多くの入力パラメーターが必要ないという理由だけでクラスを作成することは、そのクラスを作成する間違った理由です。
それはすべて、変更の結果として他の場所でどれだけのリファクタリングを行う必要があるかにかかっていると思います。すべてを新しいクラスにプッシュすると、結果としてアプリケーションの他の部分が機能しなくなりますか? これにより、いくつのバグが発生する可能性がありますか? IMO の 3 つまたは 4 つのパラメーターは問題ありませんが、5 つ以上のパラメーターを署名にプッシュし始めると、ジョブを処理するクラスを作成する傾向があります。
見積もりなどは要因になる可能性があります.1時間で仕事を終わらせなければならないが、クラスを作成し、他のコードを更新し、テストするのに3人かかる場合は、新しいパラメータを変更し、後で再検討します。