C'est donc un peu bizarre de poser deux questions consécutivement, mais elles ne sont pas très liées et je ne voulais pas les combiner, mais je ne spamme pas de questions, je le promets!

Quoi qu'il en soit, je suis un récent diplômé d'université, et mon éducation n'a touché qu'aux modèles de conception ... nous en avons mis en œuvre quelques-uns simples, avons abordé le fait qu'il y en avait plus compliqués et avons été invités à nous tourner vers le livre du GoF si nous voulait en savoir plus. Ma question est la suivante: vaut-il la peine d'apprendre les modèles du livre du GoF? Pour moi, il a toujours semblé contre-intuitif d'essayer de faire en sorte qu'un problème corresponde à un motif classique, mais évidemment le livre et les motifs sont célèbres pour une raison. Se présentent-ils suffisamment pour que je les apprenne?

Merci encore!

Comme d'habitude

Ça dépend

Cela dépend de combien de POO vous avez fait pour savoir si vous reconnaîtrez ou même pourrez utiliser les modèles de conception

Cela dépend de la façon dont vous êtes discipliné pour savoir si vous appliquerez les modèles une fois appris correctement, et ne deviendrez pas fou comme l'homme proverbial avec un marteau

D'un autre côté ... cinq doigts!

Si vous avez fait quelques années de sérieux travail de POO ou si vous avez un mentor fiable pour vous garder sur la bonne voie ou si vous aimez simplement lire OOP-nerd, alors par tous les moyens, allez acheter le livre et étudiez-le.

Il est utile de connaître les modèles afin que vous puissiez reconnaître quand les utiliser et quand ne pas les utiliser.

Oui, vous devez les apprendre.

Il est encore plus logique de les revoir après avoir acquis une certaine expérience , afin de pouvoir les comparer avec ce que vous savez. Pour certains modèles, il se trouvera que c'est quelque chose que vous avez découvert vous-même, mais vous apprendrez quelque chose de plus général sur son utilisation, ses compromis, ses variantes, etc. D'autres peuvent sembler résoudre directement les problèmes que vous avez résolus et vous montrer une solution élégante que vous ne connaissiez pas.

La grande majorité des modèles est très utile et courante . D'autres peuvent ne pas être aussi populaires, mais ont toujours une utilisation étroite où ils sont parfaitement adaptés.

Il y a une autre raison pour laquelle cela vaut la peine d'être lu: il vous apprendra à penser . Bien sûr, ce n'est pas une solution miracle, mais toujours une inspiration inestimable.

Enfin et surtout, jamais, jamais, en aucun cas, essayez de faire en sorte qu'un problème corresponde à un modèle ou à un outil . C'est une pensée très mauvaise et dangereuse! Comprenez comment l'outil fonctionne et utilisez-le judicieusement pour résoudre le problème, jamais l'inverse.

Plus vous connaissez d'outils, mieux c'est. Parfois, un outil peut inspirer votre réflexion (plutôt que de résoudre un problème directement), une autre fois, vous en combinerez quelques-uns pour une excellente solution.

Le livre GOF est une excellente source de nombreux outils utiles que nous utilisons quotidiennement .

L'avantage le plus important de connaître un peu les Design Patters est que vous savez ce que signifient les termes. En d'autres termes, vous connaissez le vocabulaire commun .

C'est, pour moi, la réalisation la plus importante de toutes les turbulences liées aux modèles de conception, un vocabulaire commun est apparu où vous pouvez simplement utiliser les noms des modèles spécifiques, et d'autres savent immédiatement de quoi vous parlez sans que vous ayez à l'expliquer . Les choses que les modèles décrivent sont bien connues de la plupart des programmeurs, mais il faut du temps pour expliquer ce que vous voulez dire aux autres, ce qui facilite la communication pour connaître les noms des modèles.

Les exemples sont Visitor, Singleton et Decorators.

En d'autres termes, je vous suggère de vous familiariser au moins avec les noms et ce qu'ils font.

OUI mais avec prudence!

La partie OUI:

Parfois, nous avons rencontré des problèmes dans nos conceptions. Parfois, ces problèmes sont très courants, donc les modèles de conception vous donnent des solutions bien testées pour ces problèmes. Les principaux avantages de l'apprentissage des modèles de conception sont que vous pouvez trouver une solution de conception beaucoup plus rapidement et si vos collègues sont conscients du jargon du modèle de conception , vous pouvez également expliquer une solution beaucoup plus rapidement.

La partie prudente:

Les modèles de conception ne doivent pas être le Saint Graal de vos solutions. La solution la plus simple (KISS) est plus souhaitée et les motifs de conception rendent souvent les choses plus complexes. Si vous apprenez les modèles de conception, découvrez également les anti-modèles. Je connais de vieilles personnes qui sont contre les modèles de conception et je suis d'accord dans une certaine mesure avec eux parce que lorsque vous n'avez pas trop d'expérience en codage mais que vous avez beaucoup de théorie des modèles de conception, vous pourriez finir par rendre les amincissements beaucoup plus difficiles pour vous et votre équipe.

Enfin, ne pensez pas que vous devez adapter / modifier votre solution juste pour respecter un modèle de conception. Au contraire, vous pouvez plier un modèle de conception afin qu'il puisse s'adapter à votre solution. Est-ce correct si vous n'utilisez pas tous les ingrédients d'une recette de modèle de conception tant que vous avez une meilleure solution à votre problème particulier. Considérez les modèles de conception comme une suggestion et non comme la règle de votre solution.

J'ai trouvé la méthode la plus bénéfique de Net Objectives pour penser aux échanges. Les gens qui lisent le livre du GoF commencent trop souvent à supposer que les structures qu'ils montrent, en notation de conception et en code, sont les modèles et que c'est toujours à quoi ils ressemblent. Il y a une manière différente et sans doute meilleure de voir les choses.

Les modèles sont des ensembles de problèmes similaires qui peuvent tous être résolus avec certaines formules abstraites, et non des ensembles de formules qui peuvent être utilisés pour résoudre divers problèmes. Cela signifie que le motif est déjà là avant même que vous ne commenciez à essayer de faire un design, l'objet du designer est donc de le trouver , pas de l'imposer.

De plus, beaucoup de gens regardent les modèles et disent: "Oh, je viens de résoudre cela en ... je n'ai pas utilisé de modèles stupides." Le fait est que "...." décrit presque inévitablement une implémentation d'une solution de modèle donnée. Par exemple, un tableau de pointeurs de fonction pourrait servir de chaîne de responsabilité même si ce n'est pas ce à quoi ressemble la recette traditionnelle.

Dans cet esprit, dans votre étude des régularités, l'accent devrait être mis sur les problèmes et non sur les régularités. Apprenez les facteurs de motivation des modèles et comment ils répondent à ces facteurs. Cela vous permettra de voir les modèles du problème et de les signaler simplement. Ceci, ainsi que le langage que les modèles nous donnent pour parler de design, vous permet d'exposer un design bien adapté pour répondre aux différentes difficultés que vous rencontrez actuellement.

OUI, en bref, les modèles d'apprentissage ne valent pas seulement la peine ... vous vous limitez en ne les apprenant pas. Je ne veux pas avoir à décrire tous les principes de motivation et la forme générale de la solution quand je dis: "On dirait un visiteur pour moi."

Voici leur site Web: http://www.netobjectives.com/PatternRepository/index.php?title=Main_Page

Les modèles de conception décrits par GoF sont en quelque sorte une extension naturelle du paradigme OO. Si vous ne comprenez pas bien les objectifs de la POO (encapsulation, séparation des préoccupations, principe DRY, modularité, etc.), alors essayer d'appliquer avec succès les modèles de conception n'a pas beaucoup de sens.

Cependant, si vous vous mouillez les pieds dans la POO du monde réel et essayez d'être fidèle aux valeurs de la POO, vous vous retrouverez inévitablement dans des situations telles que celles décrites par le GoF, et il est probable que vous inventerez des solutions similaires aux leurs. Après avoir résolu de nombreux problèmes similaires, vous pouvez commencer à voir des schémas émerger; à ce stade, il est logique de lire le livre; idéalement, vous aurez un sentiment de reconnaissance, et vous apprécierez immédiatement l'élégance et la propreté des motifs proposés. Il y a de fortes chances que vous envisagiez également certains de ces modèles sans réfléchir (ce que, une fois que vous les connaissez, beaucoup le sont). Vous pourrez également bien juger si un certain modèle est applicable dans une situation donnée.

Et voici un autre avertissement: ce n'est pas parce que vous connaissez tous ces modèles que vous devez les appliquer partout. Certains d'entre eux sont assez intelligents et les gens sont tentés de les utiliser même lorsqu'ils sont horriblement inappropriés, le modèle Singleton étant l'exemple le plus célèbre (une grande partie de la controverse Singleton vient d'une utilisation inappropriée, par exemple, quand il n'y a aucun avantage à en avoir un) - contrainte d'instance uniquement).

Les modèles de conception tentent de résoudre les problèmes de conception.

• Ils ont été créés AFAIK principalement pour les langues OOP.
• Certains problèmes n'existent pas dans la programmation fonctionnelle (le modèle de commande est de savoir comment créer des fonctions de première classe, le modèle de stratégie se rapproche de la fonction d'ordre supérieur ...). Ces modèles sont pour les langues (principalement OOP) qui n'ont pas besoin de fonctionnalités.
• Ils sont classés par ordre alphabétique. Plusieurs modèles sont la composition d'autres ou les idées sont composées de celles qui existaient auparavant.

J'ai appris les modèles plus tard, après avoir connu la programmation fonctionnelle, UML, la conception de bases de données, les structures de données et les algorithmes. En fait, je viens de parcourir la liste de conception de ces modèles sur une feuille de triche et j'ai hoché la tête que je connaissais déjà la plupart d'entre eux. Certains étaient vraiment sympas comme les schémas singleton ou "communication" (visiteur, médiateur) ...

Je suis d'accord avec les points soulevés dans plusieurs autres réponses sur la façon dont il peut être dangereux d'appliquer des modèles de conception avec peu d'expérience.

Pourtant, je recommande fortement de lire au moins le premier chapitre du livre du GoF. La première section vous présentera les modèles de conception, mais est vraiment plus sur les principes de conception OO, et cela devrait être bénéfique à lire et à comprendre même avec relativement peu d'expérience. (Certaines idées clés dont je me souviens incluent "encapsuler les concepts qui varient", "les hiérarchies d'héritage doivent être larges mais pas profondes".) C'est presque dommage que le travail soit surtout connu pour ses 23 modèles - sa discussion sur les principes de conception OO qui a informé ces modèles est également extrêmement précieux.

Ma question est la suivante: vaut-il la peine d'apprendre les modèles du livre du GoF?

Absolument! Vous devez apprendre non seulement les modèles de conception de logiciels, mais les techniques de conception en général. Apprendre des solutions communes à des problèmes communs est un début fantastique. Surtout une fois que vous commencez à creuser dans les modèles et leurs compromis.

Se présentent-ils suffisamment pour que je les apprenne?

Le livre original Gang of Four a été développé en examinant de nombreux projets logiciels et en voyant les techniques qu'un certain nombre de développeurs ont utilisées pour résoudre des problèmes. Les auteurs ont remarqué quelques très bonnes techniques, ainsi qu'un certain nombre qui ont été appliquées dans des projets très disjoints et ont travaillé à les résumer encore plus pour les utiliser quel que soit le domaine.

il a toujours semblé contre-intuitif d'essayer de faire correspondre un problème à un modèle classique

Ceci est un problème majeur. Vous ne faites pas un problème adapté à la solution. Au lieu de cela, le livre des modèles de conception Gang of Four a une section «problème» pour chaque modèle, et d'autres catalogues de modèles ont des sections similaires, qui décrivent quand vous devez appliquer chaque modèle. Il décrit également les «conséquences» de l'utilisation du modèle - si vous essayez d'éviter une conséquence, l'utilisation du modèle n'est pas la meilleure idée.