0

次のコードの何が問題になっていますか？

public class DeDoper {
    public boolean wackapediaOkToday() {
        DnsResolver resolver =  ResolverFactory.getInstance().makeResolver();
        return resolver.getIpAddressFor("wackapedia.org").equals("123.456.78.9");
    }
}

このバージョンが好まれるのはなぜですか？

public class DeDoper {
    @InjectService
    private DnsResolver resolver;
    
    public boolean wackapediaOkToday() {
        return resolver.getIpAddressFor("wackapedia.org").equals("123.456.78.9");
    }
}

ResolverFactory.makeResolver（）を簡単にモックできます。これは、resolverの設定が最新の例であるのと同じです。

これは、ProQuest.bizからのこの記事で言われたことです：

この[最初の]バージョンのWackapediaOkTodayは、非常に大まかに言えば、DnsResolverが「注入」されています（ただし、ショットを取得するようなものではなく、ウェイターにチェックを依頼するようなものです）。しかし、それはテストの問題と「ずっと下のカメ」の問題を解決します。

ファクトリにチェーンされていますが、この[最初のバージョン]アプローチでは、ファクトリクラスに文字通り「チェーン」されています。（さらに悪いことに、ファクトリによって作成されたオブジェクトに依存関係がある場合は、ファクトリ内に新しいファクトリを導入する必要があります。）制御を完全に「反転」していないため、ファクトリを内部から呼び出し（制御）しています。私たちのクラス。

必要だったのは、クラスのコントロールを完全に取り除き、（依存関係のために）何を取得しているかをクラスに伝える方法でした。

4

1 に答える 1

2

「FileLocator」のように、複数の実装を持つことができるサービスがあったとしましょう。これには、ファイルのルートへのパスを引数として取るFilesystemFileLocatorと、S3クレデンシャルを引数として取るS3FileLocatorがあります。前者では、サービスロケーターを作成して、必要なバージョンを特定し、それを返す必要があります。そのコードは、データを取得したり、適切なタイプのファイルロケーターを構築したりする必要があります。IOCコンテナーが実行する必要があることを実行しています。その上、その特定の作成方法への依存関係を注入しました。

2番目のバージョンでは、必要なファイルロケーターのタイプを（注釈またはXMLを介して）定義しました。IOCコンテナは、それをインスタンス化して管理します。維持しなければならないコードは少なくなります。また、3番目のタイプのFileLocatorを導入する場合は、作業が少なくて済みます。または、コードをリファクタリングしてファイルロケーターがシングルトンになるようにするか、シングルトンの場合は新しいロケーターのファクトリにするか、ロケーターインスタンスをプールする必要があります。これらすべての場合において、IOCコンテナを使用すると、破損が少なくなります。

于 2013-03-03T20:29:00.377 に答える