J'entends des opinions contradictoires telles que:
- "Les classes Dedicated Manager ne sont presque jamais le bon outil d'ingénierie"
- "Les classes Dedicated Manager sont (actuellement) le meilleur moyen de survivre à un grand projet avec des milliers de ressources"
Prenons une classe ResourceManager classique qui possède les fonctionnalités suivantes:
- Charge des ressources (textures, audio, modèles 3D, etc.)
- Garantit que les actifs ne sont chargés qu'une seule fois en conservant un cache
- La référence compte les actifs pour déterminer s'ils peuvent être désalloués
- Masque la provenance des actifs réels (par exemple, peut être un fichier par actif, ou tous les actifs dans un fichier de package, ou des actifs peuvent même être chargés sur le réseau)
- Peut recharger des ressources sans redémarrer le programme, ce qui est extrêmement utile pour les artistes travaillant sur le jeu.
Supprimons également l'argument "les singletons sont mauvais" de la table en prétendant que ces objets ResourceManager ne sont pas des singletons et sont plutôt transmis via l' injection de dépendances .
Ensuite, il y a l'argument «utiliser une usine» ou «l'appeler une usine». Mon problème avec cela est que, oui, c'est une usine, mais c'est aussi un cache et un rechargeur (faute d'un meilleur mot). L'appeler une usine ne le décrit pas correctement, et si j'en fais une usine correcte, alors où la mise en cache et le rechargement sont-ils implémentés?
Je suis d'accord que les classes "Manager" sont souvent le symptôme d'une mauvaise architecture, mais dans ce cas particulier comment pourrait-elle être restructurée et conserver toutes les fonctionnalités ? Est-ce une situation où une classe "Manager" est réellement appropriée?