1

Car Validatorと、その属性を読み取ってそれらを検証する多くのメソッドを想定します。したがって、それを構造化する最良の方法は、Carをインスタンスフィールドにすることです。

それを作る2つの方法：

1） Carを引数としてコンストラクターを作成し、validate（）を呼び出します。

2）すべてのコンストラクターを削除しますが、引数としてメソッドを検証するためにCarを渡します：validate（Carcar）。

このバリデーターが継続的に検証する必要があると想像すると、500台の車を考えてみましょう。

1）メソッドでは、500個のバリデータオブジェクトをインスタンス化する必要があります...ガベージコレクターがその仕事を本当にうまくやっているとしても、それはベストプラクティスではないようです。利点は、Carフィールドの初期化がコンストラクター=>によって行われるため、より自然な方法であるということです。

2）メソッドを使用すると、 1）の欠点を回避できますが、Carフィールドをメソッドvalidateに初期化する必要があります。つまり、オブジェクトの構築後です。それは良い習慣と考えられていますか？実際、検証メソッドはCarフィールドを使用するだけであり、さらに、プライベートではない検証メソッドのみがあります。

もちろん、すべての疑問を回避するためにこれを行う3番目の方法があります=>検証メソッドから各プライベートメソッドにCarを渡します...しかし、これは非常に醜いです...

3つの方法のどれを選択する必要がありますか？

4

3 に答える 3

1

4番目のアプローチを使用し、ValidatorオブジェクトをCarコンストラクターに挿入することにより、できるだけ早く車の有効性をチェックします。無効な車のインスタンスがぶら下がっていて、後で（validity（）またはValidatorオブジェクトの属性を介して）複数の場所で有効性をチェックする（つまり、速く失敗しない）必要があるよりもはるかに小さな欠点があります。

更新：たとえば、クライアント側にいるなどの理由で、構築中にCarインスタンスを検証できない場合は、Carインスタンスをサーバー側の汚染された値と見なし、汚染チェッカーとメソッド2を使用して汚染を解除します。

于 2012-04-10T11:41:50.857 に答える
1

2番目のアプローチはアンチパターンであり、避けるべきだと思います.悪名高いSimpleDateFormatクラスに似ています(ステートレスでスレッドセーフに見えますが、そうではありません)。

他のアプローチに関しては、本当に多くのプライベート メソッドがある場合は、1 番目のアプローチを使用することをお勧めします。それ以外の場合は、3 番目のアプローチを使用できます。

また、1 番目のアプローチを「そのまま」使用すると、3 番目のアプローチよりも結合が多くなることに注意してください。3 番目のケースでは、事前構成されたバリデーターのインスタンスを注入することで、バリデーターのクライアントをその実装から切り離すことができますが、1 番目のケースでは、同じ効果を得るためにファクトリーを導入する必要があります。

于 2012-04-10T11:10:01.383 に答える
1

良い実践とは、通常、欠点を回避するものです。

2 番目の方法を使用します。CarValidatorクラスを作成し、validate(car)それを呼び出してオブジェクトの有効性をチェックする場合、それは非常に効率的な方法のようです。それがベストプラクティスではないと思う理由がわかりませんか？

Carすべてのプライベート メソッドでインスタンスを渡すのではなく、プライベート変数を設定し、検証プロセス全体でそれを参照することに関心がありますか? メソッドが同期されている限りvalidate、このアプローチは問題になりません。

于 2012-04-10T11:11:29.697 に答える