En tant que développeur junior, je suis un peu confus sur certains modèles de conception. Parfois, je ne sais tout simplement pas quoi utiliser dans quel contexte.
Pour des exemples, sur les modèles de création des , je ne sais pas vraiment quand utiliser:
En fait, je vois des différences; Mais je vois aussi que vous pouvez utiliser plusieurs solutions telles que:
Je veux dire, le résultat de ces créations est à la fin de la même chose: vous obtenez une instance d'objet.
Je me demande simplement quel type de conception vous utiliserait sur différents contextes (je suppose que cela pourrait être en fonction des besoins de la performance, de la complexité des objets, du couplage ...)
En outre, je ne vois pas vraiment de grandes différences entre une façade et un médiateur , à l'exception du médiateur appelle différentes interfaces.
même pour chaîne de responsabilité , ne comprend pas vraiment pourquoi toutes les implémentations que je vois utilise des listes chaînées. Ce modèle ne peut pas être mis en œuvre avec une simple liste de gestionnaires que nous appelons successivement?
C'est pourquoi j'aimerais que les gens me disent dans quel contexte Béton vous utiliseriez un modèle GOF, et pourquoi vous n'utiliseriez aucun des autres modèles qui auraient pu être adapté à la donné problème (mais probablement de manière moins élégante).
merci
6 Réponses :
Initialement, j'ai trouvé que le moyen le plus simple d'apprendre les modèles était de rencontrer une situation qui avait besoin d'aide (trop complexe pour comprendre en un coup d'œil), puis la mettre en œuvre. Il est difficile de comprendre pourquoi un modèle est bénéfique jusqu'à ce que vous ayez un problème qui l'appelle vraiment.
Une excellente ressource pour cela est refactoring à des motifs ' par Joshua Kerievsky.
+1 pour la clarification postée dans le commentaire de ma réponse. Je suggère de modifier cette partie de cette réponse, d'être plus claire dans cela. Peut-être plus en ligne avec le commentaire: il est difficile de comprendre pourquoi un modèle est bénéfique jusqu'à ce que vous ayez un problème qui l'appelle vraiment.
Bon appel. Merci pour l'aide.
Mon point d'affichage personnel est que les modèles de conception à eux-mêmes sont généralement utilisés très limités dans le monde réel - je vois souvent des modèles vendus comme une solution de convivialité "Vous devez utiliser le modèle x", en réalité le monde réel n'est pas aussi uniforme qu'un manuel - le développement de logiciels n'est pas une exception.
Bien que la compréhension et la reconnaissance des schémas soient utiles, ne tentait pas trop d'essayer d'appliquer des "schémas de conception" aux problèmes du monde réel, utilisez plutôt la connaissance des modèles de conception comme source d'inspiration lors de la résolution de vos propres problèmes, par exemple bien que je vienne souvent Avec des solutions impliquant des aspects pouvant sembler similaires au motif usine, je n'ai pas encore écrit une classe avec le mot "usine" dans le nom.
Si cela était vraiment aussi simple que d'utiliser des motifs de conception partout, nous serions tous hors d'emploi! : -)
Comme beaucoup de gens quand je suis tombé sur des modèles de conception, j'ai compris que beaucoup d'entre eux étaient simplement des noms pour des mécanismes que j'avais déjà utilisés pour résoudre des problèmes de conception. Le problème est venu en premier, puis la solution. Je n'ai jamais approché de motifs de design comme s'ils étaient des pièces de puzzle qui devaient correspondre à quelque part.
Vous n'êtes pas vraiment obligé de répondre à un problème avec le nom d'un modèle comme s'il s'agissait d'un examen. La façon de le faire est de s'asseoir et de penser à ce que vous avez besoin de votre code et comment cela peut changer à l'avenir. C'est ainsi que nous sommes de toute façon à ces modèles de conception. Les gens ont continué à utiliser les mêmes tours pour résoudre un certain ensemble de problèmes jusqu'à ce que quelqu'un soit arrivé et a donné ces noms de tours.
Le seul problème que vous avez est le manque d'expérience et qui ne peut pas être corrigé à peine. Lorsque vous écrivez des logiciels, vous obtiendrez invariablement des choses mal. Vous découvrirez que si vous aviez fait des choses cette façon , ils auraient été meilleurs. Incidemment cette est un nom; "Abstract Factory", "Adaptateur", "Observateur", peu importe. À l'avenir, vous saurez quand et pourquoi l'utiliser. Pour le moment, souvenez-vous du principe de Kiss. Ne compliquez pas les choses qui ne doivent pas être compliquées.
Le fait que vous soyez au courant des modèles de conception avant de savoir comment les utiliser signifie que vous avez une longueur d'avance sur la plupart des Devs. Ne vous transpondrez pas trop, rappelez-vous que la prochaine fois que vous aurez un problème, l'un d'entre eux pourrait être une réponse acceptable. Petit à petit, vous découvrirez quand un motif de conception doit être utilisé et quand il ne devrait pas.
+1 spécifiquement pour "Vous n'êtes pas vraiment nécessaire de répondre à un problème avec le nom d'un modèle comme s'il s'agissait d'un examen"
+1 pour KISS (XTRA CHARS)
+1 pour "Simplement des noms pour les mécanismes que j'avais déjà utilisé". Un modèle n'est pas quelque chose que vous devez utiliser. Quelqu'un a simplement décidé de prendre le temps d'écrire toutes les solutions et d'avoir été "inventé" sur et sur les autres. En lisant gof, vous obtenez un démarrage de la tête "Inventer" votre propre solution - cela aurait pu être inventé. Ils peuvent déjà être évidents, mais maintenant ils ont un nom.
Et si je pouvais voir +1 encore pour le reste de la réponse.
Ceci est une réponse infiniment meilleure que la réponse choisie. Je l'expose, mais cela dit tout parfaitement.
J'ai manqué cette réponse, mais après 6 ans, totalement d'accord avec vous :) Au cours de mon voyage, j'utilise des modèles de conception uniquement pour l'utilisation de celui-ci, pas vraiment baiser. J'ai eu un peu de temps maintenant que je ne me soucie plus que des noms de modèle (sauf peut-être que ceux de DDD et d'événementsourcing)
Ce que je veux souligner le plus dans cette réponse, est mon désaccord avec ce bit d'une autre réponse:
C'est difficile (comme vous l'avez remarqué) d'appliquer un modèle pour la première fois et de comprendre ce que les avantages peuvent être
Vous devez voir un avantage clair que le modèle donnera avant de l'appliquer. Si ce n'est pas le cas, ne l'utilisez pas, Ajout de modèles à votre code qui ne donnent pas d'avantages clairs tomberont probablement dans un scénario anti-motif . .
C'est pourquoi j'aimerais que les gens me disent dans quel contexte concret vous utiliseriez un modèle GOF, ainsi que pour la raison pour laquelle vous n'utiliseriez aucun des autres modèles qui auraient pu correspondre au problème donné (mais probablement dans un manière moins élégante).
Tout d'abord, ne vous limitez pas à ce que vous avez lu là-bas. Les meilleurs aspects des motifs sont de vous permettre d'acquérir des options de conception à plusieurs scénarios différents.
Naturellement, il existe des scénarios pouvant être faits de plus d'une manière. En difficulté de choisir entre 2 modèles dans un scénario très spécifique? Vérifiez-les à nouveau, voyez ce qu'ils ont dit sur le scénario et les avantages.
Si vous vous trouvez submergé par la quantité de motifs, donnez la plupart d'entre eux un repos. Ne présentez pas tous les modèles dans vos compétences à la fois. Choisissez une poignée associée de ceux-ci et apprenez bien quand les appliquer (lisez-les à nouveau, recherchez / demandez des comparaisons dans les messages SO / Blog.
Faites toujours attention à la manière dont les modèles que vous avez appliqués répondent aux modifications et à la manière dont sa complexité du code autour d'eux. Demandez-vous la question sur la manière dont ces caractéristiques seraient différentes avec l'un des autres modèles alternatifs.
Enfin, comprenez que vous êtes le mieux à la suite d'une approche de code évolutif. Faites de votre mieux pour garder votre code propre, mais ne vous empêchez pas de trouver une solution qui n'aura plus jamais à changer. Même avec les modèles à portée de main, vous prendrez des hypothèses, cela peut avoir une incidence sur laquelle vous avez choisi le modèle. Les changements peuvent ne pas être conformes à ces hypothèses, est un fait ou une vie.
lire Ces 2 ebooks peuvent vous aider à vous concentrer / Développer / améliorer le code.
Je pense que nous sommes d'accord, honnêtement. On ne peut pas appliquer de modèles sans avoir un avantage à l'esprit. Cependant, je ne pouvais certainement pas comprendre «pourquoi» un modèle était bénéfique jusqu'à ce qu'il a résolu un problème qui me dérangeait. Jusqu'à ce point, c'était un diagramme dans un livre. Vous pouvez écrire beaucoup de code avant de recevoir un singleton. Cela n'arrête pas tout le monde qui a toujours lu GOF d'essayer de presser un singleton à chaque fois qu'ils veulent une excuse d'utiliser une variable globale.
@Steve Je suis complètement d'accord avec ce que vous dites dans ce commentaire. La façon dont je lis cette partie de votre réponse a été initialement ressemblait à: vous réaliserez les avantages dont vous les utilisez. Et c'est comme ça que nous obtenons la situation que vous venez de décrire, les gens qui tentent d'utiliser des schémas tout en cas de raison. Je comprends maintenant ce n'est pas ce que vous vouliez dire.
Utilisation de votre confusion créée:
usine : crée une instance de plusieurs classes dérivées
prototype : une instance entièrement initialisée à copier ou clonée
J'ai eu une affaire récemment où j'ai besoin de construire un objet qui implémente une interface. Je ne sais pas, ni je ne veux savoir quel objet (ou objets) sont utilisés pour mettre en œuvre cette interface. Depuis que je suis personnellement WANTED pour masquer les objets, je devais utiliser un et j'ai caché L'objet (s) utilisé (s) utilisé à l'intérieur de l'usine - tant que je reçois une interface, je suis bon à partir. Je ne veux même pas avoir à voir Les objets qui implémentent l'interface - ils sont un ensemble compliqué d'objets, que la personne qui les utilise n'a pas besoin d'entrer dans. Parfois, un objet est requis, parfois c'est plusieurs. C'est un détail que je veux caché à l'intérieur de l'usine. Mais vous regarde la même situation, vous semblez être axé sur l'utilisation d'un prototype i ne veux pas voir les objets, mes objets Don ' t Supporte une méthode usine :
. Cela signifie que vous devez construire des objets, définir des propriétés, puis clone comme requis. C'est bon pour vous, quand vous savez quel objet vous voulez utiliser. Vous devez également écrire un .clone () sur vos objets. clone () et je ne veux pas écrire un. Cela me ramène à l'usine modèle .
Lorsque vous donnez à l'usine, un paramètre qui dirigera l'usine de créer un objet "masqué" spécifique, ne pouviez pas également transmettre un paramètre à un constructeur (qui s'appelle un réalisateur ici) qui retournerait l'objet recherché (mise en œuvre de votre interface. )? Peut-être dans ce cas que le constructeur est également une sorte d'usine ... je suppose que cela pourrait ajouter une complexité inutile, mais cela ferait presque la même chose
Refaire au code Utiliser un Builder Patter ne m'aident pas, et cela rend les choses plus compliquées. J'utiliserais un Builder lors de la construction des différents objets est un processus compliqué - suffisamment compliqué d'écrire une classe entière conçue pour le construire pour moi. Je n'ai pas besoin de ça - juste nouveau canadatransActionValidator () . En fait, j'ai quelques cas où l'un des objets retournés validateur est mis en œuvre à l'aide de quatre ou cinq objets enfants. Mais même la construction n'est pas assez compliquée que je devrais créer une classe spécialisée dans la création de l'objet.
Il est également important de réaliser, dans mon cas, que cela ne peut pas utiliser un directeur / Builder modèle; ça ne convient pas. Vous passez un constructeur à un réalisateur . Le réalisateur méthodes d'appels sur le générateur , qui crée ensuite l'objet dont le constructeur a besoin. Cela signifie que j'aurais besoin d'un Catégorie pour chaque type d'objet résultant dont j'ai besoin. Choisir le bon objet (et la combinaison d'objets) J'ai besoin, c'est le travail de code d'exécution (dans une usine), plutôt que de pré-écrire un constructeur pour toutes les demandes possibles.
Dans mon système réel, l'interface renvoyée peut être soutenue par 25 combinaisons différentes d'objets. Je ne veux pas créer 25 constructeurs. a) c'est trop sucré; la construction n'est pas si compliquée que je dois abstrumer dans un constructeur dédié, mais aussi b) je suis trop paresseux pour le faire
usine : crée des objets sans exposer la logique d'instanciation au client.
prototype : Spécifiez les types d'objets à créer à l'aide d'une instance prototypique et créez de nouveaux objets par Copier ce prototype.
Utilisez ce modèle lorsque vous créez une instance (avec un nouvel opérateur) est coûteux. Généralement Builder : Séparez la construction d'un objet complexe de sa représentation
Utilisez ce modèle lorsque vous devez créer un objet avec peu d'attributs obligatoires et de nombreux attributs facultatifs. Fournir un constructeur pour créer un objet avec tous les attributs obligatoires et optionnels est complexe. Le constructeur facilite ce processus de construction en suivant la méthode étape par étape.
Builder se concentre sur la construction d'un objet complexe étape par étape. L'usine abstraite met l'accent sur une famille d'objets de produits (simples ou complexes). Builder retourne le produit en dernière étape, mais c'est en ce qui concerne l'usine abstraite, le produit est retourné immédiatement.
Façade fournit une interface simplifiée à un système complexe. Il enveloppe une collection d'API avec une seule API bien conçue.
Médiateur motif définit un objet (médiateur) qui encapsule la manière dont un ensemble d'objets interagissent. Il permet une communication plusieurs à plusieurs.
Postes liés:
Modèles de conception: Méthode d'usine vs usine vs abstrait usine
conserver le constructeur en classe distincte (interface courante)
Clone () est utilisé pour créer un objet à partir de l'objet existant.
DUP possible de: Stackoverflow.com/questions/ 244706 / ...
@ org.life.java Je vois celui-ci un peu différent, car il se réfère déjà à divers modèles et de sa plus concerné de savoir comment décider.