4

私は、まず第一に、15 または 20 の引数が渡された巨大なコンストラクターを持つクラスのライブラリーを使用しています。これらのクラスは 20 ほどあり、引数は似ていますが、厳密には同じではありません。引数 12 が省略されているものもあれば、指定されているが必須ではないものもあります...

これらの引数の多くは互いに関連しているため、これらの引数をオブジェクトに構成することを考えています。たとえば、FirstName、LastName、および Email Address を Person オブジェクトにします。しかし、これはいくつかのモンスター クラスにつながるようです。オブジェクトをまったく使用しないと、すべての引数が使用され、ほとんどの場合、使用される引数はわずかになります。

現在、すべての検証ロジックはすべてのコンストラクターにあります...コンストラクターを継承チェーンのかなり下にチェーンする問題を解決できれば、各クラスをオーバーライドして単純化できる抽象 Validate() メソッドを作成できますデザイン。Refactoring to Patterns を確認しましたが、この質問に直接関係していると思われるものは何も見当たりませんでした。

注: これはこれのだまされたものではありません。同様のオブジェクトではなく、同様のコンストラクターについて話しているのです。wazoo から抽象基本クラスを取得しました。

4

1 に答える 1

3

これらの引数の多くは互いに関連しているため、これらの引数をオブジェクトに構成することを考えています

それは私にとって良い一歩のように聞こえます。

しかし、これはいくつかのモンスタークラスにつながるようです

なぜそれらが「モンスター」クラスである必要があるのか​​ まったくわかりません.単純なDTOクラスとして保持できますが、電子メールアドレスが指定されている場合、それが本当に有効な電子メールであるという検証を提供したい場合があります.住所など

これにより、オブジェクトを使用しないと、すべての引数が使用されます

オブジェクトを使用しても、すべてのプロパティが使用されることはありません。DateTimeそれは問題ありません。たとえば、すべてのプロパティを使用する用途はほとんどありません。

a を作成するときにすべての値を指定する必要はありません。どの値がすべての用途にPerson本当に必要かを判断し、それらをコンストラクターに入れます。次に、パラメーターにオプションのパラメーターを使用するか、プロパティだけを使用して、可変型。したがって、次のことができます。Person

Person person = new Person("Jon", "Skeet", // Required parameters
                           email: "skeet@pobox.com"); // Optional

または：

Person person = new Person("Jon", "Skeet") { Email = "skeet@pobox.com" };

個人的には、オブジェクトが不変になる可能性があることを意味する最初のアプローチが好きですが、オプションのパラメーターについてどのように感じるかによって異なります。

いずれにせよ、他のクラスはこれらのより大きな BLOB を取得するだけで済みます (たとえば、12 の異なる参照ではなく、2 つのPerson参照と 1つLocationの参照)。大きなブロブに必要な値はすべて (コンストラクターで検証されるため) 既に入力されていると想定できます。次に、たまたま必要なオプションの値も入力されていることを確認できます。

于 2013-07-29T18:32:22.363 に答える