Etant étudiant en informatique, un de nos professeurs m'a récemment donné un aperçu des modèles de conception. Je comprenais à quoi ils servent, mais certains aspects continuent de me déranger.

Sont-ils vraiment utilisés par la majorité des programmeurs?

En parlant d’expérience, j’ai eu des problèmes lors de la programmation, des problèmes que j’ignorais depuis un moment, mais Google et quelques heures de recherche ont résolu mon problème. Si, quelque part sur le Web, je trouve un moyen de résoudre mon problème, s’agit-il d’un modèle de conception? Est-ce que je l'utilise?

Et aussi, est-ce que vous (les programmeurs) vous trouvez à la recherche de motifs (où suis-je censé chercher, au fait?) Lorsque vous commencez le développement? Si tel est le cas, c’est certainement une habitude que je dois commencer à adopter.

UPDATE: Je pense que lorsque je demande si les programmeurs les utilisent, je vous demande si, en cas de problème, vous devez résoudre le problème "Oh, je devrais utiliser ce modèle".

Quand j'étais programmeur débutant, j'aimais les motifs de conception. Je n'ai pas simplement utilisé des modèles de conception. Je leur ai infligé. Où et quand je pourrais. J'étais sans pitié. Aha! Modèle d'observateur! Prend ça! Utilisez un auditeur! Procuration! AbstractFactory! Pourquoi utiliser une couche d'abstraction alors que cinq suffiront? J'ai parlé à de nombreux programmeurs expérimentés et constaté que presque tous les lecteurs du livre GoF passent par cette étape.

Les programmeurs débutants n'utilisent pas de modèles de conception. Ils abusent des modèles de conception.

Plus récemment, j’ai constaté que le fait de garder à l’esprit des principes tels que le principe de responsabilité unique et de rédiger d’abord des tests permettait aux modèles d’ émerger de manière plus pragmatique. Quand je reconnais les motifs, je peux continuer à les progresser plus facilement. Je les reconnais, mais je n'essaie plus de les forcer à coder. Si un modèle de visiteur apparaît, c'est probablement parce que j'ai redéfini la duplication, pas parce que j'ai réfléchi à l'avance aux similitudes entre le rendu d'un arbre et l'ajout de ses valeurs.

Les programmeurs expérimentés n'utilisent pas de modèles de conception. Les modèles de conception les utilisent.

Que l' on les reconnaît ou non, la plupart des programmeurs font des modèles d'utilisation.

Cependant, dans le travail quotidien, on ne commence pas à programmer avec un motif en tête - on reconnaît qu’un motif est apparu dans le code puis on le nomme.

Certains modèles courants sont intégrés à certaines langues, par exemple, le modèle d'itérateur est intégré à C # avec le foreachmot clé.

Parfois, vous connaissez déjà le modèle que vous utiliserez comme solution commune au problème (par exemple, le modèle de référentiel - vous savez déjà que vous souhaitez représenter vos données sous la forme d'une collection en mémoire).

Comme l'indique la réponse pdr liée: les modèles de conception sont des noms donnés à des choses que les gens faisaient de toute façon , dans le but de faciliter la discussion aux gens.

En général, cela vaut la peine de les apprendre à leurs débuts, car ils vous donnent un aperçu des solutions que les gens ont trouvées pour que vous puissiez travailler; vous pouvez donc vous appuyer sur des années d'expérience et sur des essais et erreurs.

La discussion sur les problèmes de motivation inclus dans les modèles peut vous donner une idée des bonnes façons d’attaquer votre problème, mais à moins que votre connaissance du modèle ne vous permette de reconnaître qu’il existe une solution connue, il vous reste à vous concentrer sur la résolution du problème. problème d' abord.

S'il s'avère que vous utilisez un ou plusieurs modèles existants, alors tant mieux, vous avez des noms prêts à l'emploi qui aideront les autres à comprendre votre code.

De manière générale, non. Il y a des moments où des modèles émergent de mon code, mais en général, je ne les cherche pas et je ne dis certainement pas "Oh, le modèle de pont résoudrait mon problème!".

Voici la chose. La plupart des modèles sont maltraités et mal utilisés sans que les gens ne se demandent s'ils sont bien conçus. Les modèles ne sont pas des atomes. Le code ne comprend pas la permutation X des motifs. Sans compter que tous les modèles ne sont pas en réalité de bonnes idées ou que certaines langues ont des solutions au niveau de la langue largement supérieures à certains modèles.

oui, la plupart des programmeurs que j'ai rencontrés utilisent le modèle le plus courant, le Big Ball of Mud . Ils commencent généralement avec des architectures bien conçues, mais finissent généralement ici, surtout s’ils commencent à penser "nous devons utiliser des modèles de conception" un peu partout et les refactoriser sans merci.

les utilisez-vous?

Oui, les programmeurs expérimentés le font certainement. Vous pouvez éviter d'utiliser la plupart des modèles de conception (à l'exception des éléments simples sur un singleton) pour l'instant; mais plus vous programmez et plus vous construisez de systèmes complexes, plus vous ressentirez le besoin d'utiliser des modèles de conception. Si vous continuez à l'éviter, vous commencerez à ressentir la douleur lorsque vous devrez développer votre système et le modifier conformément aux nouvelles exigences.

Si, quelque part sur le Web, je trouve un moyen de résoudre mon problème, s’agit-il d’un modèle de conception?

Pas nécessairement. Un modèle de conception fait référence à un moyen spécifique de concevoir des classes, leurs comportements et leurs interactions pour atteindre un objectif spécifique (ou éviter un problème spécifique). Ce que vous avez pu rencontrer n’est peut-être pas vraiment un problème de conception, mais une séquence spécifique d’étapes pour programmer une certaine API. Par exemple: il existe une certaine séquence pour établir une connexion socket. Faites-le mal et votre socket ne communiquera pas. Cette séquence d'étapes ne constitue pas un motif.

est-ce que vous (les programmeurs) vous trouvez à la recherche de motifs

Oui. Les modèles de conception incarnent l’axiome "mieux vaut prévenir que guérir". Si vous pouvez repérer au préalable un problème de conception particulier à venir, vous pouvez empêcher de nouvelles conceptions en profondeur afin de prendre en compte les modifications ultérieures. Il est donc utile de connaître à l'avance les modèles de conception et de rechercher les emplacements où vous devez les utiliser lors de la création de votre application.

Où suis-je censé chercher?

Depuis que vous êtes étudiant, vous n'avez probablement pas vu les problèmes typiques qui inspirent les modèles de conception. Je vous recommande fortement de regarder les modèles de conception Head First . Ils présentent d’abord un problème de conception puis montrent comment un motif particulier peut le résoudre / l’éviter.

Les motifs de conception n'étaient pas enseignés quand j'étais à l'école. Et, pendant la majeure partie de ma carrière en programmation, j'ai travaillé avec du code traditionnel, non orienté objet. Ces dernières années, j'ai essayé de les apprendre car elles sonnaient comme une bonne idée. Cependant, je dois avouer que chaque fois que je prends un livre ou que je tente de lire un tutoriel sur le sujet, mes yeux sont vitreux et je n’ai vraiment rien appris de concret à leur sujet.

Je ne peux pas croire que je viens d'admettre cela en public. Je pense que j'ai probablement juste perdu tout crédit geek que j'ai pu établir au fil des ans.

Ne cherchez pas tendance

Toute solution de programmation standard pour un problème donné peut être considérée comme un modèle de conception, peu importe sa popularité, que les autres programmeurs les utilisent ou non.

Vous utilisez peut-être déjà un modèle de conception qui n'a pas encore été inventé / spécifié.

N'essayez pas de les utiliser, essayez de penser selon leurs termes

Le problème avec les modèles de conception est que parfois les programmeurs veulent y adapter leurs problèmes quand c'est l'inverse.

N'oubliez pas que les conventions de conception des modèles de conception ont un problème typique à résoudre. Vous pouvez même combiner des modèles de conception pour résoudre d'autres problèmes plus importants. C’est un peu typique des architectures orientées services, il suffit de voir quelques-uns des modèles de SOA qui existent .

Cherchez-les à l'état sauvage

Il existe de nombreux projets open source dans lesquels vous trouverez des modèles de conception appliqués. Joomla est un exemple qui me vient à l’esprit: vous trouverez des singletons , des observateurs . Les bibliothèques GUI auront le motif décorateur , motif de commande mis en œuvre, et peut - être même poids mouche .

Il existe d’autres modèles, tels que les modèles de données, par exemple le projet Doctrine seul, le modèle d’enregistrement actif (1.x), le modèle de gestionnaire d’entités (2.x), l’ unité de travail , le référentiel , l’objet de requête , le mappage de métadonnées , les données. la cartographie , et d'autres plus générales comme le modèle de stratégie et le modèle de décorateur .

Il y a tellement de solutions intéressantes à choisir. Voir Patterns of Enterprise Architecture de Martin Fowler , il existe également des modèles de modèle de données .

Il suffit de les apprendre pour le moment venu

Apprenez-les, connaissez-les, obsédez-les et, le moment venu, vous saurez résoudre le problème de programmation x, vous serez déjà un meilleur programmeur à ce moment-là.

Devenir architecte

Je dirais qu'être capable de penser selon un modèle pour résoudre des problèmes fait de vous un architecte de logiciel . Même si vous ne voulez pas être un architecte logiciel en tant que tel, vos solutions auront davantage de qualité technique, seront plus propres et auront une meilleure évolutivité - en termes de conception - par défaut.

J'ai programmé pendant environ 7 ans en C ++ et appris des modèles il y a environ 2 ans. La plupart des motifs ont probablement des applications, mais dans mon utilisation, certains sont meilleurs que d'autres. Vous devez penser pourquoi vous les utilisez.

Le modèle d'itérateur a en fait rendu mon code plus confus et a ajouté une complexité inutile. Je peux obtenir la même maintenabilité en utilisant typedefs pour les types de vecteurs STL. Et toute modification apportée à la classe étant itérée, je dois également apporter à la classe itérateur.

La méthode d'usine, cependant, s'est avérée extrêmement utile, basée sur le polymorphisme qu'elle fournit. J'oublie qui a dit cela, mais l'affirmation "réutilisabilité signifie que l'ancien code peut utiliser un nouveau code" est certainement vraie avec le modèle d'usine.

J'ai utilisé le modèle de méthode de modèle pendant des années sans même savoir qu'il s'agissait d'un "modèle de conception".

Le modèle Observer a été utile dans certains cas, parfois non. Vous devez parfois prévoir la complexité pour déterminer si la complexité de la structure Observer en vaut la peine. Nous avons un programme qui utilise environ 10 abonnés et il pourrait y en avoir beaucoup plus. Le modèle observateur / abonné a donc été utile. Un autre programme, cependant, a deux écrans graphiques. J'ai mis en œuvre le modèle d'observateur pour ce programme, qui était en grande partie inutile, simplement parce que cela ajoutait de la complexité et que je ne prévois pas d'ajouter d'autres écrans.

Je pense que ceux qui recommandent de toujours utiliser des modèles supposent que votre programme sera infiniment complexe, mais comme pour tout, il existe un seuil de rentabilité en termes de complexité.

Ajout à Lunivore. J'aimerais citer ceci du premier livre en tête

        ## **Three steps to great software** ##     

• Assurez-vous que le logiciel fait ce que le client veut
• Appliquer de bons principes orientés objet
• S'efforcer d'obtenir une conception maintenable et réutilisable

C’est au cours de la troisième étape, une fois que votre système fonctionne comme prévu. Il est temps d’appliquer les modèles pour rendre votre logiciel prêt pour les années à venir.

Sont-ils vraiment utilisés par la majorité des programmeurs?

Je suppose que oui. Dans ADO.Net, il existe une classe DataAdapter pour donner un exemple simple, mais selon le domaine dans lequel vous souhaitez spécialiser les modèles, cela peut varier.

En parlant d’expérience, j’ai eu des problèmes lors de la programmation, des problèmes que j’ai été incapable de résoudre pendant un moment, mais Google et quelques heures de recherche ont résolu mon problème. Si, quelque part sur le Web, je trouve un moyen de résoudre mon problème, s’agit-il d’un modèle de conception? Est-ce que je l'utilise?

Non, ce n'est pas un motif de conception dans mon esprit. Un modèle de conception a généralement un arrangement de classes et de méthodes qui définissent la recette d’un modèle.

Je préférerais penser à ce que vous avez fait là-bas comme une pratique courante. Attention toutefois au codage par copier / coller.

Et aussi, est-ce que vous (les programmeurs) vous trouvez à la recherche de motifs (où suis-je censé chercher?) Quand vous commencez le développement? Si tel est le cas, c’est certainement une habitude que je dois commencer à adopter.

Parfois, lorsque je vois le même code encore et encore, je peux trouver un moyen de le reformuler en un motif ou, si je me souviens d'une solution à un problème similaire impliquant un motif, je le sors et l'utilise. Head First Design Patterns contient plus de quelques modèles, alors que la refactorisation serait une suggestion de pratiques de codage pouvant conduire à la recherche de différents modèles. Si vous voulez un autre point de départ possible, consultez Patterns and Practices de Microsoft .

Les modèles d'apprentissage ne consistent pas simplement à apprendre quelque chose. Vous apprenez ce que vous pouvez faire avec les langages de programmation. J'ai moi-même beaucoup appris sur la programmation orientée objet en apprenant simplement comment fonctionne un modèle (le modèle composite dans ce cas).

Comme mentionné par Oded, la plupart des programmeurs les utilisent parfois sans même le reconnaître. La beauté des motifs réside dans le fait que vous pouvez traiter des problèmes spécifiques avec un motif prédéfini afin de ne pas avoir à trop penser à des choses architecturales.

Vous apprendrez des modèles lorsque vous commencerez à travailler avec des projets existants. Il y a tellement de modèles à apprendre pour vous, et il ne vaut pas la peine de les maîtriser tous, cela dépend du projet sur lequel vous travaillez. Chaque fois que vous en rencontrez un, découvrez-le pour voir comment il est utilisé.