現在、ABC オブジェクトを作成する単一のメソッドを持つ ABCFactory クラスを作成しました。考えてみると、ファクトリを持つ代わりに、ABC メソッドで静的メソッドを作成することもできます。この変更の長所と短所は何ですか? それは同じにつながりませんか？他のクラスが ABC を継承することはないと思いますが、わかりません!
ありがとう
6 に答える
4
単一の静的メソッドを使用すると、これをテストするのがはるかに困難になりますが、インスタンス化可能なオブジェクトを使用すると、テストが容易になります。また、依存性注入は、後で非静的ソリューションのオプションになります。
もちろん、これが必要ない場合、これらは良い議論ではありません。
于 2010-04-01T21:06:57.133 に答える
3
ファクトリ メソッドの主な利点は、特定のクラスへの参照をインターフェイスの背後に隠すことができることです。静的メソッドはインターフェースの一部にすることができないため、静的ファクトリ メソッドは基本的にコンストラクター メソッド自体と同じです。静的ファクトリ メソッドの唯一の有用なアプリケーションは、プライベート コンストラクター (シングルトン パターンの実装に一般的に使用されるコンストラクター) へのアクセスを提供することです。
于 2010-04-01T21:29:41.297 に答える
2
実際には、ファクトリ クラスの利点を得るには、独自のクラスに静的メソッドが必要です。これにより、後で新しいファクトリ クラスを作成したり、既存のファクトリ クラスを再構成して異なる動作を取得したりできます。たとえば、あるファクトリ クラスは、IFourHoovedAnimal インターフェイスを実装する Unicorns を作成する場合があります。IFourHoovedAnimal を処理するアルゴリズムを作成し、それらをインスタンス化する必要がある場合があります。後で、代わりに IFourHoovedAnimal も実装する Pegasus をインスタンス化する新しいファクトリ クラスを作成できます。新しいファクトリを使用するだけで、古いアルゴリズムをペガサスで再利用できるようになりました。これを機能させるには、PegasusFactory と UnicornFactory の両方が共通の基本クラス (通常は抽象クラス) から継承する必要があります。
したがって、静的メソッドを独自のファクトリ クラスに配置することで、ファクトリ クラスを新しいものと交換して、古いアルゴリズムを再利用できることがわかります。これは、モック オブジェクトを作成するファクトリに単体テストを提供できるため、テスト容易性の向上にも役立ちます。
私は非常に小さなプロジェクトのために後者（インスタンスを作成しているクラスの静的ファクトリメソッド）を以前に実行しましたが、それは古いコードをリファクタリングするのに必要でしたが、変更を最小限に抑えるために必要だったからです。基本的に、その場合、一連の ASP.NET コントロールを作成するコードのチャンクを取り出し、それらすべてのコントロールをユーザー コントロールに詰め込みました。新しいユーザー コントロールのプロパティ ベースを作成したかったのですが、古いレガシ コードでは、パラメーター ベースのコンストラクターを使用してユーザー コントロールを作成する方が簡単でした。
そこで、すべてのパラメーターを受け取る静的ファクトリ メソッドを作成し、ユーザー コントロールをインスタンス化し、パラメーターに基づいてそのプロパティを設定しました。古いレガシ コードでは、この静的メソッドを使用してユーザー コントロールを作成していましたが、将来のコードでは、代わりに「よりきれいな」プロパティを使用する予定です。
于 2010-04-01T21:12:56.443 に答える
1
具体的なクラスの場合、ファクトリメソッドは実際には実際の型を作成するための間接的なメソッドにすぎません（これは有用ではないというわけではありませんが、ご覧のとおり、ファクトリメソッドは実際にはどこにでもあります）。
ファクトリメソッドが本当に優れているのは、メソッドがインターフェイスタイプのインスタンスを作成するときです。
于 2010-04-01T21:06:42.790 に答える
1
ボブおじさんのオブジェクト指向設計のSOLIDPrinciplesの「D」は、 「依存性逆転の原則」です。具体化ではなく、抽象化に依存します。
その原則に極端に従うと、メインクラスがすべてのファクトリを作成し、各ファクトリがインターフェイスを介して他のファクトリを使用する可能性があります。「新しい」（具体的なオブジェクトを作成する）の唯一の外観は、メインクラスと工場にあります。すべてのオブジェクトは、提供されたファクトリ実装から取得された具体的な依存関係を使用して、インターフェイス（抽象化）で機能します。
その後、非常に簡単に調整したり、さまざまなシナリオに合わせてカスタマイズされた複数のメインクラスを提供したりできます。
于 2010-04-01T22:14:06.273 に答える
1
設計パターンの乱用は危険であり、インターフェイスが定義されたクラス階層がある場合や、かなり複雑なオブジェクトを構築する必要がある場合は、創造的な設計パターンが理にかなっています。シンプルなデザインの場合は、シンプルなソリューションを使用してください。したがって、あなたの場合、ファクトリーメソッドで十分です
はい、そうです、それは別のデザインパターンです:)
于 2010-04-02T07:20:09.117 に答える