Impossible de saisir les modèles de conception de programmation

16

Je travaille avec javascript depuis 4 ans. Je suis très confiant quant à mes compétences en résolution de problèmes et je peux voir que la qualité de mon code s'améliore. J'essaie de rester à jour avec la communauté et je travaille actuellement avec ES2015 et React.js. Cependant, je sens que je ne peux pas du tout saisir les modèles de conception de programmation. Je sais où trouver des ressources à ce sujet et j'ai déjà lu des livres à ce sujet. Je compte sur mes collègues seniors pour prendre des décisions sur la structure du projet mais je n'ai aucun problème à y travailler.

Chaque fois que j'ai besoin de démarrer quelque chose par moi-même, je cherche ces deux chemins: Si j'utilise une grande bibliothèque / framework comme React.js, j'ai tendance à copier ce que fait la communauté; Si je suis sur quelque chose de plus petit, j'utiliserai le modèle de module. Je sais qu'une fois que je comprendrai mieux ce sujet, je pourrai prendre de meilleures décisions, mais pour l'instant je suis complètement perdu.

Dois-je rechercher une éducation supérieure à ce sujet? Ai-je besoin d'un mentor sur ce sujet? Suis-je juste stupide? Est-ce vraiment difficile à comprendre?

design-patterns javascript

— Abensur
source

6

À mon avis, certaines langues sont plus «indulgentes» que d'autres en ce qui concerne la nécessité d'utiliser des modèles de conception. Les langages compilés fortement typés (comme Java et C #) sont plus affectés par une mauvaise conception que les langages de script faiblement typés comme JavaScript et PHP. Cela ne veut pas dire que les modèles de conception ne sont pas utiles aux deux, bien sûr.

— Matthew

3

La taille du projet joue également un rôle important.

— Matthew

2

@Matthew nitpick Je n'appellerais pas nécessairement Java / C # fortement typé ...

— Jared Smith

2

@JaredSmith true, j'oublie souvent la distinction entre fortement typé et statique.

— Matthew

6

Si vous essayez de comprendre les modèles en général , arrêtez ! Il n'y a rien là-bas! Un modèle est une solution populaire à un problème courant et quelqu'un lui a donné un nom. C'est tout ce qu'on peut en dire. Vous pourriez avoir du mal à saisir un modèle spécifique - J'ai du mal à me souvenir comment utiliser efficacement le modèle "visiteur" pour imiter la double répartition en Java - Mais si vous recherchez la sauce secrète qui relie "visiteur" pour dire "objet de transfert de données", vous ne le trouverez pas. Ce ne sont que deux solutions populaires à deux problèmes communs, quelqu'un leur a donné des noms et les noms sont restés.

— Solomon Slow

34

Les modèles de conception de logiciels sont des solutions bien connues à des problèmes bien connus. La façon dont vous les comprenez est d'apprendre les modèles, de comprendre comment ils fonctionnent et de savoir quand il convient de les appliquer à la conception de votre logiciel.

La façon dont vous apprenez les modèles de conception de logiciels consiste à les étudier un par un. C'est un processus d'éducation continue. Si vous souhaitez réduire l'empreinte d'apprentissage, étudiez les modèles qui se rapportent directement aux technologies que vous utilisez actuellement.

Quelques informations importantes à savoir sur les modèles de conception:

Certains modèles de conception sont de nature architecturale. MVC et MVVM sont des exemples de tels modèles. Vous utilisez de tels modèles lorsque vous avez besoin des avantages organisationnels et structurels qu'ils fournissent.
Certains modèles de conception sont des solutions de contournement aux déficiences des langages de programmation. Vous n'aurez pas besoin de ces modèles si vous utilisez un langage de programmation plus expressif, mais souvent vous ne faites pas ce choix. La majorité des modèles du GoF sont dans cette catégorie .
Utilisez un modèle logiciel uniquement lorsque vous essayez de résoudre le problème que le modèle est spécifiquement conçu pour résoudre. Si vous écrivez une application en assemblant des modèles de logiciels, vous vous trompez.
Il n'y a pas de modèle logiciel existant pour chaque problème informatique existant. Si tel était le cas, la programmation ne serait qu'un exercice de correspondance de motifs.
Certains modèles sont en fait anti-modèles. La complexité supplémentaire que ces modèles introduisent l'emporte sur les avantages qu'ils offrent. Vous devrez décider par vous-même, modèle par modèle, lequel de ces modèles vous éviterez.

— Robert Harvey
source

Bonne réponse, bien que je ne sois pas d'accord avec l'affirmation selon laquelle la plupart des modèles GoF sont une solution de contournement pour les déficiences des langages de programmation. Souvent, certains modèles sont mieux applicables à certaines langues, oui, car les langues ont tendance à être conçues en fonction de certains problèmes et solutions.

— Polygnome

1

Les motifs Gof ont 20 ans. La plupart d'entre eux ont été créés pour résoudre des problèmes avec C ++, problèmes hérités par Java car Java est basé sur C ++.

— Robert Harvey

Le paradoxe de cette réponse est la partie "problème bien connu". Il est difficile de comprendre ces «problèmes bien connus» si vous ne les avez jamais rencontrés.

— Fuhrmanator

2

Java n'est pas basé sur C ++. La syntaxe javas est inspirée du C ++, mais ce n'est certainement pas basé sur lui. les deux langues fonctionnent assez différemment. Du fait que le matériel Java abstact gère la mémoire par lui-même, sans avoir de modèles mais plutôt des génériques, etc.

— Polygnome

4

L'approche de chacun en matière d'apprentissage est un peu différente, et je n'ai aucune idée de votre approche générale, mais je crois que vous vous rendez un mauvais service en vous qualifiant de "stupide".

Personnellement, d'après mes observations sur ce que beaucoup qualifieraient d'ingénieurs, de concepteurs de logiciels «réussis», tous ont un thème commun à leur apprentissage: «l'expérience». Je crois que c'est votre "éducation supérieure" et vous en apprendrez plus rapidement que d'acheter des tonnes de livres sur Amazon et de les lire (une mauvaise habitude).

Ainsi, par exemple, prenez un modèle GOF comme le modèle de commande et implémentez-le dans la langue de votre choix. Comprenez quels avantages cela vous apporte et quels sont les inconvénients. Les différents livres sur les modèles de conception vous l'expliqueront, mais je pense qu'il vaut mieux appliquer ces connaissances pratiquement et en tirer des leçons. Ne négligez pas le matériel de lecture, ils ont un but, mais le monde de l'informatique n'est guère un exercice de manuel. Cela étant dit, c'est mon opinion et ma vision du monde de l'informatique et en partie, représente ses propres difficultés au début de ma carrière en génie logiciel. En outre, un problème majeur que je vois, même avec des développeurs de logiciels très expérimentés, c'est l'impatience et l'oubli de profiter de ce qu'ils font. Alors, prenez votre temps avec ce que vous apprenez et n'oubliez pas d'apprécier réellement ce que vous faites, sinon pourquoi prendre la peine d'y consacrer du temps?

De plus, profitez de l'expérience pratique des autres. Il existe une pléthore de solutions open source, à la fois mauvaises et bonnes, et vous pouvez en tirer des leçons. Regardez comment ils ont appliqué des modèles et réfléchissez à la façon dont vous aborderiez le problème différemment.

Donc, mon conseil général est que si vous sentez que votre approche est mauvaise, changez-la. Regardez les gens autour de vous qui, selon vous, apprennent le matériel que vous pensez ne pas saisir et regardez ce qu'ils font ou même leur demandez.

— Planète désolée
source

1

Je pense vraiment que la programmation est comme le jeu d'échecs. Vous avez peut-être un talent natif, vous pouvez y jouer toute la journée, mais si vous ne lisez pas de livres sur les échecs, vous ne pouvez faire aucun progrès et, plus important, vous ne pouvez pas apprécier la beauté du jeu.

— Adrian Iftode

@AdrianIftode - d'accord. Comme mentionné, je n'écarterais pas les livres, les blogs ou tout autre matériel de lecture, mais c'est un problème commun que j'ai rencontré avec des gens qui s'efforcent de maîtriser un langage de programmation / une plate-forme / un cadre, etc. et apparemment ils ont fait peu de codage et / ou de pratique effort, mais avoir lu tous les livres, vous pouvez secouer un bâton.

— Desolate Planet

@AdrianIftode Eh bien, pas précisément. Jouer aux échecs sans lire de livres, vous pouvez toujours en apprendre beaucoup sur le jeu. La seule différence est que vous n'apprenez pas aussi vite que possible en vous appuyant sur certaines expériences et réflexions de maîtres d'échecs. D'un autre côté, en pensant à certaines choses, vous pouvez tomber sur une ou deux solutions qui ont été totalement ignorées par les personnes qui n'apprennent que des maîtres d'échecs et que vous pourriez utiliser à votre avantage. En fin de compte, je crois qu'un mélange des deux types d'apprentissage offre le meilleur avantage. Aux échecs comme en programmation.

— cmaster - réintègre monica

1

La réponse courte est que vous n'en avez pas besoin . Vous pouvez écrire du code sans eux. Comme Matthew l'a dit dans les commentaires, cela est particulièrement vrai en JavaScript où le langage est assez flexible et les projets ont tendance à être plus petits. Mais si vous programmez depuis 4 ans, j'ai du mal à croire que vous ne soyez pas tombé sur des choses répétitives ou maladroites. Ce sont ces zones que vous redécouvrez ou qui manquent de motifs de conception.

Exemple: le système d'événements JavaScript est souvent inadapté à la tâche à accomplir. Ne vous trouvez-vous jamais désireux de pouvoir combiner ou transformer des flux d'événements? Ou cette série d'événements étaient des valeurs de première classe à part entière? Vous avez besoin des modèles Mediator et / ou Observer. Besoin d'une liaison de données bidirectionnelle? Même histoire.

La hiérarchie fragile du prototype s'est abattue? Mixin / Trait / Subclass Factory patterns à la rescousse.

— Jared Smith
source

4

Il est pratiquement impossible d'écrire un programme non trivial sans utiliser de modèles de conception, généralement vous en utiliserez également de nombreux. Ce dont vous n'avez pas besoin, c'est de pouvoir reconnaître les modèles que vous utilisez par leur nom. Vous pouvez écrire du code de travail même si vous ne pouvez pas nommer tous les modèles de conception que vous utilisez dans le code.

— Servy

Les modèles @Servy Design sont des abstractions, les abstractions ne sont pas strictement nécessaires. Vous pouvez toujours écrire une implémentation ponctuelle ponctuelle du comportement sous-jacent ... encore et encore et encore. Par exemple, dans l'exemple que j'ai donné à propos des événements, il est possible de câbler manuellement toutes les parties concernées, puis de les modifier à chaque fois que les exigences changent, ça craint juste par rapport à l'utilisation de pub / sub. Pour les sous-classes, il est possible (si inutile) de coder manuellement dans toutes les possibilités avec un tas de classes uniques, ce n'est tout simplement pas aussi bon.

— Jared Smith

1

Les modèles de conception peuvent devenir très larges. Souvent, les modèles de conception plus larges sont si évidents que nous ne les considérons même pas comme des modèles de conception (en particulier lorsqu'ils ont un support linguistique spécial). Une boucle est un modèle de conception. Les fonctions sont un modèle de conception. Les objets sont un modèle de conception.

— Servy

@Servy si c'est comme ça que vous utilisez le terme, alors je ne suis pas en désaccord, mais j'ai l'impression que l'OP signifiait spécifiquement les modèles GOFish.

— Jared Smith

1

@JaredSmith Les modèles de conception ne sont pas des abstractions. Même si vous les implémentez encore et encore et encore pour le problème concret que vous avez, ce sont toujours des modèles . Vous n'avez pas besoin d'écrire une classe Observer générique et de l'utiliser pour utiliser le modèle Observer . Écrire des observateurs concrets et des méthodes concrètes pour les enregistrer et les notifier utilise toujours le modèle. la chose difficile est de reconnaître le motif. Parfois, vous utilisez un motif sans même connaître son nom,

— Polygnome

1

Trouvez un mentor, quelqu'un avec une très bonne expérience pour apprendre. Posez-lui des questions, regardez son code, soumettez une révision de code et essayez de collaborer avec lui. C'est la meilleure façon d'améliorer vos compétences en codage.

supplémentaire:

Collaborez à un projet OSS simple que vous aimez
Lorsqu'il existe deux façons de résoudre le même problème, choisissez toujours le plus simple
Construisez une expérience supplémentaire avec des projets parallèles où vous êtes libre de faire toutes sortes d'erreurs étranges, et vous apprendrez le modèle de conception "à la dure" (tm)

— Motocarota
source