Les modèles de conception sont-ils généralement une force positive ou négative? [fermé]

J'ai entendu dire que les modèles de conception sont la meilleure chose depuis le pain en tranches. J'ai aussi entendu dire que les modèles de conception ont tendance à exacerber le "syndrome du second système", qu'ils sont massivement surutilisés et qu'ils incitent leurs utilisateurs à penser qu'ils sont de meilleurs concepteurs qu'ils ne le sont réellement.

J'ai tendance à tomber plus près de l'ancien camp, mais récemment, j'ai vu des concepts où presque chaque interaction est remplacée par une relation d'observateur, et tout est un singleton.

Alors, considérant les avantages et les problèmes, les modèles de conception sont-ils généralement bons ou mauvais, et pourquoi?

Les modèles de conception sont une langue et non un conseil pour écrire un programme ou un contrat. Leur utilisation principale est une explication a posteriori de la manière dont un composant ou un système a été (ou sera) mis en œuvre. Au lieu d'entrer dans trop de détails, vous pouvez simplement dire quelques mots qui décrivent suffisamment bien la mise en œuvre pour que l'auditeur puisse comprendre comment cela fonctionne et ce qui était important.

Alex: Comment les fichiers de configuration sont-ils créés?

Bob: Ils sont générés par une usine, qui réside à config.h.

Maintenant, Alex sait que la création de fichiers de configuration nécessite des préparations non triviales, car sinon, leur création ne serait pas enfermée dans une usine.

Cependant, si Bob était un imitateur à motifs et utilisait des motifs ici et là, Alex ne pourrait rien dire à propos de la création de configuration, car Bob utilisait une usine un peu partout. Cela conduirait également à une complexité excessive du programme.

Donc, programmez d'abord, puis repérez les motifs dans votre code, et non l'inverse. Voilà comment ils sont utilisés efficacement.

Les modèles de conception sont excellents . Utilisés correctement, ils rendent le code plus facile à gérer, à lire et à utiliser. Pour être un bon programmeur, il est essentiel de savoir quand arrêter et voir que toute refactorisation supplémentaire l'emportera sur les avantages. Utiliser uniquement des modèles de conception ne fait pas de quelqu'un un bon programmeur, mais savoir quand et où les utiliser est le cas. Comme dans tout autre monde, les modèles de design peuvent être poussés à l'extrême et être maltraités. Je sais que je cherche toujours (et je le ferai longtemps) cet équilibre parfait dans mon code, où chaque motif de conception a une raison d'être et se met parfaitement en place, tout comme un casse-tête.

Les modèles de conception sont excellents s'ils sont utilisés correctement.

Il est utile de rappeler que l’idée des modèles de conception est née de l’architecture. L'architecture peut varier énormément. Cependant, de nombreuses idées de base sont présentes dans tous les bâtiments. De cette manière, considérez les motifs comme des blocs de construction. Il est important de noter que tous les bâtiments ne comprennent pas tous les modèles architecturaux possibles.

Disons que vous concevez une maison. Plutôt que de laisser la porte d'entrée ouverte sur la rue, vous voulez un endroit abrité avant d'entrer dans la maison, c'est-à-dire une antichambre. Cette zone correspondra à un certain modèle. À savoir, il aura deux entrées, des murs et probablement un toit. Notez que le motif ne spécifie pas les portes, les fenêtres ni le nombre de murs. Dans la plupart des applications, il y aura deux portes, quatre murs et peut-être des fenêtres. Cependant, le motif décrit une zone fermée avec deux entrées. L'un mène dans l'antichambre même depuis l'extérieur de la maison et l'autre mène au reste de la maison. La clé ici est que si vous voulez une antichambre, vous devez entourer une zone et fournir deux entrées dans cette zone.

Les problèmes typiques rencontrés avec les modèles de conception dans la programmation sont la surutilisation et la conviction qu’ils sont une solution miracle pour résoudre tout problème. Ils ne sont pas. Ce sont des moyens de communiquer et de réfléchir à des idées de programmation utiles. Si les éléments de syntaxe d'une langue particulière sont des briques et du mortier, les modèles décrivent des moyens utiles pour les organiser de manière à répondre à certains besoins.

Je considère que les modèles de conception sont davantage des " conseils " qu'un contrat immuable qui doit absolument être respecté. Pourquoi? Justement pour la raison que vous avez mentionnée. Suivre un modèle de conception dans tout conduit à un grand désordre de code qui contrecarre le but d'utiliser un modèle en premier lieu.

C'est pourquoi je déteste les sites comme Java Practices . Certes, certaines des idées sont bonnes, mais l’auteur a alors décidé d’écrire un programme complet (plus un cadre) en suivant chaque modèle de conception qu’il a mentionné. L’auteur a également écrit chaque article avec de grosses citations effrayantes faisant penser au lecteur que les pratiques réelles de Java sont horribles et qu’elles devraient être évitées comme la peste.

TL; DR: Utiliser des modèles de conception. Juste n'abusent pas d'eux

Voir aussi ce fil sur SO. Un autre modèle de conception de POV est le code standard afin de compenser les lacunes de la méthodologie utilisée. Je ne suis pas fan de ces solutions de contournement.

Je préférerai ceux au milieu. Comme l'affiche à juste titre, comprendre les modèles ne fait pas de vous un bon développeur. D'autre part, une compréhension du modèle vous aidera à devenir un bon développeur.

Comprendre la relation entre les modèles et voir un modèle dans un projet (au stade de la conception) est ce qui fera de vous un bon développeur.

On dit souvent que les modèles de conception offrent une solution toute prête pour les problèmes de programmation. Quel genre de problèmes sont-ils? "Comment puis-je modifier le comportement des objets tout en isolant les modifications du reste du système?"

Les modèles GoF sont reconnus pour fournir cet isolement (encapsulation) du reste du système, mais il est souvent difficile de savoir quelle partie du système présente une variabilité due à l'utilisation de leurs modèles de conception. Au lieu de suivre le schéma de classification proposé (créationnel, comportemental et structurel), j'ai tracé les différences entre les modèles et proposé deux autres systèmes pour classifier leurs modèles: cycle de vie et hiérarchie d'encapsulation des composants.

Comme vous pouvez le voir dans ce tableau pour la hiérarchie d'encapsulation, les modèles de conception peuvent être appliqués à chaque niveau d'un composant. Mais cela aurait-il un sens? Le composant doit-il fournir une variation de comportement au niveau d’encapsulation proposé, et le modèle approprié est-il utilisé pour ce niveau? Si ces questions ne sont pas correctement répondues, les modèles de conception sont probablement mal appliqués. Le simple fait qu'un pivot vertical puisse être intégré à la cabine d'une voiture n'en fait pas une idée intelligente.

En utilisant une analogie avec l'argent, un modèle de conception doit être considéré comme une solution avec un coût en capital élevé mais des coûts d'exploitation faibles. Les modèles de conception coûtent une fortune dès le départ en termes de codage supplémentaire, de verbosité et de poids conceptuel résultant de l'indirection supplémentaire qu'ils créent. Ils ont également tendance à verrouiller d'autres aspects de votre conception. Par exemple, l'utilisation de la méthode template vous oblige à programmer dans un style fortement orienté objet.

Toutefois, si vous avez besoin de résoudre de nombreux problèmes étroitement liés qui varient légèrement, ou si vous allez certainement avoir besoin de modifier profondément un élément de code de manière spécifique à l'avenir, les coûts initiaux peuvent en valoir la peine, car la conception les modèles ajoutent de la flexibilité à votre code. Les modifications ou la solution à la seconde de votre ensemble de problèmes étroitement liés seront beaucoup plus faciles avec des modèles que sans.

Les deux camps sont corrects - ils sont une force pour le bien lorsqu'ils sont utilisés correctement, une force pour le mal s'ils sont éclaboussés de partout.

Les modèles de conception peuvent vous attirer, mais il en va de même pour le codage en général. Il est facile de se laisser séduire en écrivant la boîte à outils ultime - vous devez simplement garder YAGNI à l'esprit pour ne pas vous perdre, prenez conscience de la structure dont l'application a besoin. OMI c'est juste à l'individu et une marque de son expérience / jugement.

Je pense aux datterns de conception et non à quelque chose que vous essayez constamment d'appliquer à votre code. Pour moi, il s’agit principalement d’un langage commun pour les développeurs. Il est plus facile de dire «nous suivons un modèle de constructeur» que d’expliquer encore et encore.

Je relis actuellement Patterns Of Enterprise Application Architecture , car je tombe sur beaucoup de code qui suit l'un des modèles de ce livre. Je ne pense pas qu'il ait été choisi intentionnellement pour suivre l'un des schémas, mais il est certainement utile de pouvoir dire « c'est un script de transaction » et que tout le monde comprend bien ce que cela signifie.

Mais j'aime bien l'idée que vous puissiez choisir parmi un catalogue de motifs préparé, lorsque vous concevez une nouvelle fonctionnalité ou une toute nouvelle application. Pourquoi tout réinventer s’il existe des solutions éprouvées à certains problèmes?