Comprendre les usines et dois-je les utiliser?

Question

Je ne l'ai jamais utilisé les usines avant pour la simple raison, je ne comprends pas quand je les ai besoin. Je travaille sur un petit jeu dans mon temps libre, et j'ai décidé de mettre en œuvre FMOD pour le son. Je regardais un emballage conçu pour OpenAL (différente de la configuration du son) et il avait l'air quelque chose comme ...

* SoundObject SoundObjectManager * SoundObjectFactory *

Le SoundObject était essentiellement l'instance de chaque objet sonore. Le SoundObjectManager gère juste tous ces objets. Ceci est directement obtenir en avant assez et fait beaucoup de sens, mais je ne pas ce que l'usine fait ou ce qu'il est utilisé. J'ai lu sur factorys mais ne les sont pas vraiment.

Toute aide serait appréciée!

Answer 1

Pensez à l'usine comme un « constructeur virtuel ». Il vous permet de construire des objets avec un type de compilation commune, mais différents types d'exécution. Vous pouvez changer de comportement tout simplement en disant à l'usine pour créer une instance d'un type différent d'exécution.

Answer 2

Les usines sont utilisées pour la mise en œuvre doit être paramétrées. FMOD est multiplateforme, il doit décider la mise en œuvre concrète de vous donner pour votre plate-forme. C'est ce que l'usine fait. Il existe deux principaux modèles Résumé usine modèle et Méthode usine modèle .

Answer 3

Situation Hypothétique: J'écris une bibliothèque sonore que je veux courir sur plusieurs plates-formes. Je vais essayer de faire autant du code que la plate-forme possible d'être indépendant, mais certainement certaines d'entre elles devront changer pour Windows versus Mac OS X par rapport à Linux.

Alors j'écris toutes ces différentes implémentations, mais je ne veux pas l'utilisateur final d'avoir à faire leur programme dépendent de Linux ou Windows ou autre. Je ne veux pas aussi de maintenir 4 interfaces différentes à mon API. (Notez que ce ne sont que quelques-unes des raisons pour lesquelles vous pouvez créer une usine - il y a certainement d'autres situations).

Je décris cette belle classe de base générique SoundObject qui définit toutes les méthodes que le client est autorisé à utiliser. Ensuite, je fais mon LinuxSoundObject, WindowsSoundObject, et 5 autres dérivent de SoundObject. Mais je vais cacher toutes ces mises en œuvre concrètes de l'utilisateur et ne leur fournir un SoundObject. Au lieu de cela, vous devez appeler mon SoundObjectFactory pour saisir ce que vous semble être une ancienne plaine SoundObject, mais vraiment je l'ai choisi le type d'exécution correct pour vous et instancié moi-même.

2 ans plus tard, un nouveau système d'exploitation se réalise et se déplace de Windows. Au lieu de vous forcer à réécrire votre logiciel, mettre à jour juste ma bibliothèque pour soutenir la nouvelle plate-forme et vous ne verrez jamais un changement à l'interface.

Tout cela est assez artificiel, mais nous espérons que vous avez l'idée.

Les usines isolent les consommateurs d'une interface de ce type à l'exécution (à savoir la mise en œuvre) est réellement utilisé.

Answer 4

Les usines peuvent être utilisées pour mettre en œuvre l'inversion de contrôle, et de séparer le code d'instanciation (les nouvelles de) de la logique de vos composants. Ceci est utile lorsque vous écrivez des tests unitaires puisque vous ne voulez pas des objets testés pour créer un tas d'autres objets.