単純な理由で、以前にファクトリを使用したことがありません。いつ必要になるかわかりません。空き時間に小さなゲームに取り組んでいたので、サウンドに FMOD を実装することにしました。OpenAL（異なるサウンド設定）用に設計されたラッパーを見たところ、次のように見えました...
SoundObject* SoundObjectManager* SoundObjectFactory*
SoundObject は、基本的に各サウンド オブジェクトのインスタンスです。SoundObjectManager は、これらすべてのオブジェクトを管理するだけです。これは単純明快で十分に理にかなっていますが、工場が何をしているのか、何を使用しているのかわかりません。私は工場について読んでいますが、まだ実際には理解していません。
どんな助けでも大歓迎です！
Factory を「仮想コンストラクター」と考えてください。これにより、コンパイル時の型が共通で実行時の型が異なるオブジェクトを構築できます。異なるランタイム タイプのインスタンスを作成するように Factory に指示するだけで、動作を切り替えることができます。
ファクトリは、実装をパラメータ化する必要がある場合に使用されます。FMOD はクロス プラットフォームです。プラットフォームにどの具体的な実装を提供するかを決定する必要があります。それがファクトリーが行っていることです。Abstract Factory パターンとFactory Method パターンの 2 つの主要なパターンがあります。
仮定の状況: 複数のプラットフォームで実行したいサウンド ライブラリを作成しています。できるだけ多くのコードをプラットフォームに依存しないようにしますが、Windows と OSX と Linux で変更する必要があるコードもあります。
だから私はこれらのさまざまな実装をすべて書いていますが、エンドユーザーが自分のプログラムを Linux や Windows などに依存させなければならないようにしたくありません。また、API への 4 つの異なるインターフェイスを維持したくありません。(これらはファクトリを作成する理由の一部にすぎないことに注意してください。他の状況も確かにあります)。
そこで、クライアントが使用するすべてのメソッドを定義する、この優れた汎用SoundObject基本クラスを定義します。次に、LinuxSoundObject、WindowsSoundObject、および から派生した他の 5 つを作成しSoundObjectます。しかし、これらすべての具体的な実装をユーザーから隠し、SoundObject. 代わりに、 my を呼び出してSoundObjectFactory、普通の古い に見えるものを取得する必要がありますSoundObjectが、実際には、正しいランタイム タイプを選択し、自分でインスタンス化しました。
2 年後、新しい OS が登場し、Windows に取って代わります。ソフトウェアの書き直しを強制する代わりに、新しいプラットフォームをサポートするようにライブラリを更新するだけで、インターフェイスに変更が見られることはありません。
これはすべてかなり不自然ですが、うまくいけばアイデアが得られます。
ファクトリは、インターフェイスのコンシューマーを、実際に使用されているランタイム タイプ (つまり、実装) から分離します。
ファクトリを使用して、制御の反転を実装し、インスタンス化コード (「新しい」) をコンポーネントのロジックから分離できます。これは、単体テストを作成する場合に役立ちます。テスト対象のオブジェクトが他のオブジェクトの束を作成することを望まない場合があるからです。