Occasions applicables:
7.3 Occasions applicables pour le modèle d'usine
La façon la plus simple de créer un nouvel objet est d'utiliser le nouveau mot-clé et les classes concrètes. À certaines occasions, la complexité supplémentaire de la création et du maintien d'une usine d'objets en vaut la peine. Cette section résume ces occasions.
7.3.1 Implémentation dynamique
Si vous devez créer des objets qui implémentent la même interface de différentes manières, comme l'exemple de vélo précédent, vous pouvez utiliser une méthode d'usine ou un objet d'usine simple pour simplifier le processus de sélection de l'implémentation. Ce choix peut être fait explicitement ou implicitement. Le premier est comme l'exemple de vélo, et le client peut choisir le modèle de vélo dont vous avez besoin; tandis que l'exemple d'usine XHR mentionné dans la section suivante appartient à ce dernier. Le type d'objet de connexion renvoyé dans cet exemple dépend des facteurs de bande passante et de retard de réseau détectés. Dans ces situations, vous devez généralement faire face à une série de classes qui implémentent la même interface et peuvent être traitées de manière égale. C'est la raison la plus courante d'utiliser le modèle d'usine en JavaScript.
7.3.2 Enregistrer les paramètres au-dessus
Si les objets doivent être complexes et pertinents les uns envers les autres, l'utilisation du mode d'usine peut réduire la quantité de code requise pour chaque objet. Cet effet est particulièrement important si ce paramètre ne doit être effectué qu'une seule fois pour toutes les instances d'un type particulier. Mettre ce code de réglage dans le constructeur de classe n'est pas une approche efficace, car même si le travail de paramètre est terminé, le code sera toujours exécuté à chaque fois qu'une nouvelle instance sera créée, et cela distribuera le code de réglage dans différentes classes. La méthode d'usine est parfaite pour cette occasion. Il peut être défini immédiatement avant d'instancier tous les objets requis. Peu importe le nombre de classes différentes instanciées, cette méthode peut conserver le code de configuration en un seul endroit.
Ceci est particulièrement utile si la classe utilisée nécessite le chargement de la bibliothèque externe. Les méthodes d'usine peuvent vérifier ces bibliothèques et charger dynamiquement celles qui ne sont pas trouvées. Ces codes de paramètres existent à un seul endroit, il est donc beaucoup plus pratique de les modifier plus tard.
7.3.3 Faire un grand objet avec de nombreux petits objets
La méthode d'usine peut être utilisée pour créer des objets qui résument de nombreux objets plus petits. Considérez le constructeur de l'objet vélo. Les vélos contiennent de nombreux sous-systèmes plus petits: roues, cadres, composants de transmission et freins. Si vous ne voulez pas un couplage solide entre un sous-système et un objet plus grand, mais que vous souhaitez choisir parmi de nombreux sous-systèmes lors de l'exécution, alors l'approche d'usine est un choix idéal. En utilisant cette technologie, vous pouvez un jour faire correspondre tous les vélos que vous vendez avec une sorte de chaîne, et si vous trouvez une autre chaîne plus préférée le lendemain, vous pouvez utiliser cette nouvelle variété à la place. Il est facile de mettre en œuvre ce changement car les constructeurs de ces classes de vélo ne dépendent pas d'une variété de chaîne particulière. L'exemple de lecteur RSS plus loin dans ce chapitre démontre l'utilisation du modèle d'usine à cet égard.
Le modèle d'usine fournit principalement une interface pour créer des objets. Le modèle d'usine est divisé en trois catégories en fonction des termes de "Java and Pattern":
1. Usine simple
2. Méthode d'usine
3. Factory abstraite
Ces trois modèles sont progressivement abstraits de haut en bas et sont plus généraux. Il existe également une méthode de classification, qui est de considérer le modèle d'usine simple comme un cas particulier du modèle de méthode d'usine, et les deux sont classés dans la même catégorie. Voici deux situations où le mode d'usine est utilisé:
1. Lors de l'encodage, vous ne pouvez pas prévoir le type d'instances que vous devez créer.
2. Le système ne doit pas s'appuyer sur les détails de la façon dont les instances de classe de produits sont créées, combinées et exprimées
3. modèle d'usine simple
Comme son nom l'indique, ce modèle lui-même est simple et est utilisé dans des situations où l'entreprise est plus simple.
Il se compose de trois rôles (voir le diagramme de classe ci-dessous pour la relation):
1. Rôle d'usine: c'est le cœur de ce modèle, qui contient une certaine logique métier et une logique de jugement. En Java, il est souvent mis en œuvre par une classe de béton.
2. Rôle du produit abstrait: il s'agit généralement d'une classe de parents héritée par un produit spécifique ou une interface implémentée. Implémenté par interfaces ou classes abstraites en Java.
3. Rôle de produit spécifique: l'objet créé par la classe d'usine est une instance de ce rôle. Implémenté par une classe concrète en Java.
Alors, comment utiliser le modèle d'usine simple? Permettez-moi de vous donner un exemple. Je pense que c'est beaucoup plus facile à comprendre qu'une longue description de texte théorique! Voici le traitement du nouveau Riche: P
Après avoir utilisé le modèle d'usine simple, le Nouveau Riche n'a désormais besoin que de s'asseoir dans la voiture et de dire au conducteur: "conduite". Voyons comment il est mis en œuvre:
// Rôle du produit abstrait Car d'interface publique {public void Drive (); } // Rôle de produit spécifique Classe publique Benz implémente Car {public void Drive () {System.out.println ("Driving Benz"); }} classe publique BMW implémente Car {public void Drive () {System.out.println ("Driving BMW"); }}. . . (Je n'écrirai pas Audi: P) // Rôle de classe d'usine Public Class Driver {// Méthode d'usine // Notez que le type de retour est un rôle de produit abstrait Public Static Car DriverCar (String S) lève une exception {// Judge Logic, Retour le rôle de produit spécifique au client if (S.EqualSignoreCase ("Benz")) Return new Benz (); else if (s.equalSignoreCase ("bmw")) renvoie nouveau BMW (); ...... Sinon lance une nouvelle exception (); . . . // Bienvenue au Nouveau Riche à apparaître ... MAGNATE DE CLASSE PUBLIQUE {public static void main (String [] args) {try {// dire au conducteur que je prends une voiture Mercedes-Benz Car = Driver.DriverCar ("Benz"); // donne la commande: le lecteur (); . .Si vous mettez toutes les classes dans un seul fichier, n'oubliez pas qu'une seule classe est déclarée publique. La relation entre les classes d'un programme est la suivante:
Ceci est le modèle d'usine simple. Voici les avantages:
Tout d'abord, après avoir utilisé le modèle simple d'usine, notre programme n'est pas "malade" et est plus conforme à la réalité; et le client est exempté de la responsabilité de créer directement des objets de produit, mais n'est responsable que de la «consommation» de produits (comme le fait le Nouveau Riche).
Analysons le modèle d'usine simple à partir du principe de l'ouverture et de la fermeture. Lorsque le Nouveau Riche ajoute une voiture, tant qu'elle respecte le contrat formulé par le produit abstrait, il peut être utilisé par le client tant qu'il est informé de l'usine. Ainsi, pour la partie du produit, il est conforme au principe de l'ouverture et de la fermeture - ouverture pour l'expansion et la fermeture pour la modification; Mais la partie d'usine ne semble pas être idéale, car chaque fois qu'une voiture est ajoutée, la logique commerciale et la logique de jugement correspondant doivent être ajoutées à la classe d'usine, ce qui viole naturellement le principe de l'ouverture et de la fermeture.
Pour une telle classe d'usine (dans notre cas pour le conducteur), nous l'appelons la classe Tout-Puissant ou la classe God.
L'exemple que nous donnons est le cas le plus simple, et dans des applications pratiques, il est probable que le produit soit une structure d'arbres à plusieurs niveaux. Puisqu'il n'y a qu'une seule classe d'usine dans le modèle d'usine simple pour correspondre à ces produits, cela peut ruiner notre classe Dieu et épuiser à son tour nos jolis programmeurs :(
Comme je l'ai mentionné plus tôt, le modèle d'usine simple convient aux situations où l'entreprise sera simple. Mais il n'est peut-être pas très adaptable aux environnements commerciaux complexes. Cela devrait être fait par le modèle de méthode d'usine! !
4. Modèle de méthode d'usine
Jetons un coup d'œil à sa composition d'abord:
1. Rôle d'usine abstrait: c'est le cœur du modèle de méthode d'usine, cela n'a rien à voir avec l'application. Il s'agit d'une interface qu'un rôle d'usine spécifique doit implémenter ou une classe parent qui doit être héritée. En Java, il est implémenté par des classes abstraites ou des interfaces.
2. Rôle d'usine spécifique: il contient du code lié à une logique métier spécifique. Appelé par l'application pour créer l'objet de produit spécifique correspondant. En Java, il est implémenté par des classes concrètes.
3. Rôle du produit abstrait: c'est la classe parent héritée par un produit spécifique ou une interface implémentée. En Java, il existe généralement des classes ou des interfaces abstraites pour les implémenter.
4. Rôle du produit spécifique: L'objet créé par un rôle d'usine spécifique est un exemple de ce rôle. Implémenté par des classes concrètes en Java.
Utilisez des diagrammes de classe pour représenter clairement la relation entre eux:
Utilisons un exemple complet pour voir comment les différents rôles du modèle d'usine sont coordonnés. En parlant de l'entreprise Nouveau Riche, plus ils aiment les voitures. Cela a fait souffrir le conducteur. Il devait se souvenir et maintenir n'importe quelle voiture, et il a dû l'utiliser! Donc, le nouveau Riche a sympathisé avec lui et a dit: Cela dépend de vos années avec moi, vous n'aurez pas à travailler si dur à l'avenir. Je vais vous attribuer quelques membres du personnel, il suffit de prendre soin d'eux! Par conséquent, la gestion du modèle de méthode d'usine a émergé. Le code est le suivant:
// Rôles de produit abstrait, les rôles de produit spécifiques sont similaires au modèle d'usine simple, mais ils sont devenus un peu plus compliqués, voici un peu omis. // Rabate d'usine abstraite Public Interface Driver {public Car DriverCar (); } public class Benzdriver implémente le pilote {public car pilotecar () {return new Benz (); }} classe publique BMWDriver implémente le pilote {public car pilotecar () {return new BMW (); }} ...... // il devrait former une relation correspondante avec le produit spécifique, ici ... // demande à M. Nouveaux public class Magnate {public static void main (String [] args) {try {Driver Driver = new Benzdriver (); Voiture car = driver.driverCar (); car.drive (); } catch (exception e) {}}}La méthode d'usine utilise un rôle d'usine abstrait comme noyau au lieu d'utiliser des classes concrètes comme noyau dans un modèle d'usine simple. Jetons un coup d'œil à ce que le modèle de méthode d'usine nous a apporté? Utilisez le principe de l'ouverture et de la fermeture pour analyser le modèle de méthode d'usine. Lorsqu'un nouveau produit (c'est-à-dire la voiture du nouveau riche) est généré, tant qu'il est généré selon le contrat fourni par le rôle de produit abstrait et le rôle d'usine abstrait, il peut être utilisé par le client sans avoir à modifier aucun code existant. Il semble que le modèle de méthode d'usine soit entièrement conforme au principe de l'ouverture et de la fermeture!
L'utilisation du modèle d'approche d'usine est suffisante pour faire face à la plupart des besoins commerciaux que nous pouvons rencontrer. Cependant, lorsqu'il existe de nombreux types de produits, un grand nombre de catégories d'usines correspondantes apparaîtront, ce qui ne devrait pas être ce que nous espérons. Je suggère donc d'utiliser un modèle d'usine simple dans ce cas combiné avec le modèle de méthode d'usine pour réduire la classe d'usine: c'est-à-dire en utilisant un modèle d'usine simple pour des espèces similaires sur l'arbre du produit (généralement ceux qui sont des frères dans les feuilles de l'arbre).
Bien sûr, des circonstances spéciales doivent être traitées avec un traitement spécial: pour différents arbres de produits dans le système et il existe des familles de produits sur les arbres de produits, alors dans ce cas, le modèle d'usine abstrait peut être utilisé.
5. Résumé
Jetons un coup d'œil à l'inspiration donnée par le modèle d'usine simple et le modèle de méthode d'usine:
Si nous n'utilisons pas de modèle d'usine pour implémenter notre exemple, peut-être que le code sera beaucoup moins élevé - il suffit d'implémenter la voiture existante, sans utiliser de polymorphisme. Mais en termes de maintenabilité, l'évolutivité est très mauvaise (vous pouvez imaginer la classe que vous souhaitez toucher après avoir ajouté une voiture). Par conséquent, afin d'améliorer l'évolutivité et la maintenance, il vaut la peine d'écrire plus de code.
6. Modèle d'usine abstrait
Comprenons d'abord ce qu'est une famille de produits: une famille de produits composée de fonctions situées dans différentes hiérarchies et structures de produits. Si vous pouvez clairement comprendre ce concept en lisant simplement cette phrase, je dois vous admirer. Utilisons un exemple pour l'illustrer de façon vivante.
BMWCAR et Benzcar sur la figure sont deux arbres de produit (hiérarchie des produits); tandis que BenzsportsScar et BMWSportscar, comme le montre la figure, une famille de produits. Ils peuvent tous être placés dans la famille des voitures de sport, donc les fonctions sont liées. De même, BMWBUSSINGSCAR et BenzSportsScar sont également la même famille de produits.
Pour en revenir au sujet du modèle de produit abstrait, on peut dire que la différence entre elle et le modèle de méthode d'usine réside dans la complexité de la nécessité de créer des objets. De plus, le modèle d'usine abstrait est le plus abstrait et le plus général parmi les trois. Le motif de l'usine abstrait est de fournir une interface au client pour créer des objets de produit dans plusieurs familles de produits. De plus, les conditions suivantes doivent être remplies lors de l'utilisation du modèle d'usine abstrait:
1. Il existe plusieurs familles de produits dans le système, et le système ne peut consommer que l'un des produits à la fois.
2. Utilisez des produits appartenant à la même famille de produits.
Jetons un coup d'œil aux différents rôles du modèle d'usine abstrait (tout comme la même méthode d'usine):
Résumé d'usine abstrait: c'est le cœur du modèle de méthode d'usine, cela n'a rien à voir avec l'application. Il s'agit d'une interface qu'un rôle d'usine spécifique doit implémenter ou une classe parent qui doit être héritée. En Java, il est implémenté par des classes abstraites ou des interfaces.
Rôle d'usine spécifique: il contient du code lié à une logique métier spécifique. Appelé par l'application pour créer l'objet de produit spécifique correspondant. En Java, il est implémenté par des classes concrètes.
Rôle du produit abstrait: il s'agit de la classe parent ou de l'interface d'implémentation de l'héritage spécifique du produit. En Java, il existe généralement des classes ou des interfaces abstraites pour les implémenter.
Rôle de produit spécifique: L'objet créé par un rôle d'usine spécifique est une instance de ce rôle. Implémenté par des classes concrètes en Java.
Après avoir lu les deux premiers modes, je devrais avoir une idée claire de la coordination entre les différents personnages de ce mode, donc je ne donnerai pas d'exemples spécifiques. C’est juste que vous devez prêter attention à remplir les conditions d’utilisation du modèle d’usine abstrait, sinon même s’il y a plusieurs arbres de produits, il existe toujours des familles de produits, mais elles ne peuvent pas être utilisées.
L'article ci-dessus a une compréhension approfondie des trois modèles d'usine de Java. C'est tout le contenu que je partage avec vous. J'espère que vous pourrez vous faire référence et j'espère que vous pourrez soutenir Wulin.com plus.