3

簡単にテストできるオブジェクトを作成しようとしているときに、このようなコンストラクターが作成されました。

 public UserProvider(
            IFactory<IContainer> containerFactory,
            IRepositoryFactory<IUserRepository> userRepositoryFactory,
            IFactory<IRoleProvider> roleProviderFactory,
            IFactory<IAuthenticationProvider> authenticationProviderFactory,
            IFactory<IEmailAdapter> emailAdapterFactory,
            IFactory<IGuidAdapter> guidAdapterFactory,
            IRepositoryFactory<IVehicleRepository> vehicleRepositoryFactory,
            IRepositoryFactory<IUserVehicleRepository> userVehicleRepositoryFactory,
            IFactory<IDateTimeAdapter> dateTimeAdapterFactory)

これは、オブジェクトが持つすべての依存関係であり、私が持っている最も忙しいコンストラクターです。しかし、誰かがこれを見た場合、それは本当に大きなwtfを上げるでしょうか？

私の目的は、テストが簡単なロジックを作成することでした。かなりの量のモックが必要ですが、私のロジックを検証するのは確かに非常に簡単です。しかし、私は私があまりにも多くの良いことをしてしまうかもしれないのではないかと心配しています。

これがiocを実装しているほとんどの人にとって正常であるかどうか私は興味があります。

私が行うことができるいくつかの単純化があります-内部状態がないのでアダプターを直接渡すことができるので、いくつかのアダプターの工場を実際に渡す必要はありません。しかし、私はパラメータの数に関して本当に質問しています。

またはそれ以上に、私が船外に出ないという保証を探しています;）

しかし、私はUserProviderクラスを少し分解する必要があるという印象を持ち始めていますが、その後、この懸念を引き起こしているのはさらに多くの配管になってしまいます。

これらの懸念がある場合、サブ質問はおそらくサービスロケーターパターンの使用を検討する必要があると思いますか？

4

2 に答える 2

7

DI とコンストラクター インジェクションを使用すると、SRP の違反が非常に目立つようになります。これは実際には良いことであり、DI / IOC のせいではありません。コンストラクター インジェクションを使用していない場合、クラスは同じ依存関係を持つことになり、表示されなくなります。

具体的な例でできることは、関連する依存関係の一部をファサードの背後に隠すことです。たとえば、IVehicleRepository と IUserVehicleRepository を IVehicle ファサードの背後に隠すことができます。IUserRepository、IRoleProvider、および IAuthenticationProvider をファサードの背後に配置することも理にかなっています。

于 2012-06-01T16:30:00.123 に答える
3

私の意見では、それはコンストラクターの多くのパラメーターです。テスト容易性を高め、「コードの匂い」を軽減するために、これを処理する方法を次に示します。

  1. ファクトリを渡してクラスのインスタンスを作成する代わりに、クラス自体を渡すだけです。これにより、依存関係が自動的に半分に削減されます。これは、UserProvider が必要なオブジェクトを作成することに関心がないため (その後、必要に応じてそれらを破棄するため)、オブジェクトの作成に必要なファクトリを使用する代わりに、与えられたものを使用するだけだからです。必要なインスタンス。
  2. コンストラクターからアダプターを削除し、UserProvider 内でこれらのインターフェイスのインスタンスを作成するだけです。たとえば、GUID のフォーマット方法をどのくらいの頻度で変更する必要があるかを考えてみてください。アダプターに多くの依存関係がない限り、これはまだテスト可能です。

私が言いたいのは、テスト容易性と実用性のバランスを取ることです。Ioc を実装するときは、過去にテストのしやすさで問題があった場所と、依存関係が多すぎてコードの保守と変更に問題があった場所を特定してみてください。それが最もメリットが見られる場所です。

于 2012-06-01T16:46:03.460 に答える