Les modèles de conception étouffent-ils la créativité

Il y a de nombreuses années, je parlais avec un professeur d'économie des modèles de conception, de la façon dont ils établissaient un langage commun pour les programmeurs et comment ils résolvaient les problèmes bien connus d'une manière agréable, etc., etc.

Puis il m'a répondu que c'était exactement l'approche inverse qu'il utiliserait pour ses étudiants en économie. Il présentait généralement un problème et leur demandait de trouver une solution d'abord, afin qu'ils puissent y réfléchir en premier et essayer de trouver des moyens de résoudre le problème d'abord, et seulement après cela, il a présenté la solution "classique".

Je pensais donc si l'approche du "modèle de conception" est vraiment quelque chose qui rend les programmeurs plus intelligents ou plus stupides, car ils obtiennent souvent la "bonne solution à ce problème" au lieu d'utiliser la créativité et l'imagination pour résoudre un problème dans un manière nouvelle et innovante.

Qu'est-ce que tu penses?

Votre professeur d'économie a tout à fait raison.

Les modèles de conception de logiciels sont principalement un moyen pour les développeurs de logiciels expérimentés de communiquer entre eux . Ils sont un raccourci pour les solutions établies aux problèmes connus.

Mais ils ne doivent être utilisés que par des personnes qui comprennent comment résoudre le problème sans le schéma ou qui ont élaboré un schéma similaire par elles-mêmes. Sinon, ils auront le même problème que le codeur copier / coller; ils auront du code, mais ils ne comprendront pas comment cela fonctionne et ne pourront donc pas le dépanner.

En outre, bon nombre des modèles de conception sont des modèles d' entreprise , des modèles qui sont destinés à être utilisés dans de grands systèmes logiciels d'entreprise. Si vous apprenez les merveilles du conteneur Inversion of Control, vous voudrez l'utiliser dans chaque programme que vous écrivez, même si la plupart des programmes n'en ont pas réellement besoin (il existe de meilleures façons d'injecter vos dépendances dans des programmes plus petits, pas besoin d'un conteneur IoC).

Apprenez les modèles. Comprendre les modèles et leur utilisation appropriée. Sachez comment résoudre le même problème sans le modèle (tous les modèles logiciels sont des abstractions sur des algorithmes fondamentaux). Ensuite, vous pourrez utiliser les modèles de logiciels en toute confiance, lorsque cela est logique de le faire.

La façon dont les utilisateurs de Design Patterns souhaitent que vous examiniez Design Patterns est un ensemble de solutions que vous pouvez appliquer en cas de problèmes similaires. Ils ne veulent pas que vous les considériez comme les seules solutions possibles, données par Dieu à Moïse gravées dans des tablettes de pierre sur la montagne.

Malheureusement, certaines personnes les considèrent comme quelque chose de plus proche de l'écriture sainte que d'un tas d'exemples de conceptions dont on pourrait tirer des leçons. Cela tue la créativité et crée un culte du fret.

Votre professeur d'économie a mentionné avoir présenté aux étudiants le problème et leur avoir demandé de le résoudre en premier, ce qui est une bonne technique pédagogique, mais il avait une solution à leur montrer. Avoir un tas de solutions à de nombreux problèmes différents dans votre tête est une bonne chose, et c'est quelque chose que Design Patterns essaie d'être. Je pense qu'il échoue à certains égards (Singleton encourageant les mauvaises approches, une focalisation myope sur l'impératif OO, etc.), mais il pourrait être bien utilisé avec intelligence et goût. Cependant, c'est une erreur de penser que chaque exemple de solution possible dans le logiciel doit être un modèle de conception officiel.

Si vous regardez un problème et vous demandez "Quel est le modèle de conception pour cela?", Vous vous trompez, et vous serez moins susceptible de voir une solution qui vous regarde en face.

Si vous regardez un problème et vous demandez "Comment puis-je résoudre ce problème?", Alors s'il y a une solution non-modèle, vous le verrez, et s'il y a un modèle qui convient, vous le verrez aussi.

Je pense aussi que votre professeur d'économie a raison et c'est une façon d'apprendre quoi que ce soit en premier lieu; Mais regardons comme ceci: voudriez-vous garder la roue secrète et laisser tout le monde la réinventer, dans un souci de créativité ? Je m'attends à ce que vous disiez non, parce que tous les gens ne sont pas faits / capables d'inventer leurs roues - et s'ils le sont, ils le feront à un moment donné, peu importe s'ils sont conscients de l'existence de la roue ou ne pas.

Revenons aux programmeurs; Je suis un développeur Web de jour, donc MVC est l'une de ces choses avec lesquelles j'interagis quotidiennement. Plusieurs fois, j'ai essayé de construire mes propres structures, j'ai beaucoup appris, mais elles ont toutes échoué. J'ai fait de mon mieux, mais que se passerait-il s'il n'y avait pas de MVC? Eh bien, simple, mon code source est nul - en termes de fiabilité, de maintenabilité et d'extensibilité.

Je pense que c'est la même chose pour la plupart d'entre nous. Si personne ne vous parle de DI - en tant que bonne pratique, alors combien d'applications d'entreprise devraient avoir du mal ou échouer jusqu'à ce que leurs développeurs apprennent la leçon?

Le deuxième point concerne les normes de l'industrie . Si vous n'enseignez pas le MVC aux développeurs Web, êtes-vous prêt à affronter toutes ces structures non standard dont vous avez besoin pour passer un peu de temps à apprendre leur façon de faire les choses en premier, puis vous vous rendez compte que certaines de ces structures pourraient ont une bonne idée, mais la plupart d'entre eux auront de graves défauts de conception qui pourraient avoir de graves conséquences pour votre projet logiciel - même les cadres bien connus ont toujours des problèmes de conception de temps en temps.

Mais que se passerait-il si nous avions toutes ces bonnes idées et les rassemblions toutes et que ces développeurs intelligents tirent les bonnes choses de toutes ces expériences et créent une structure vraiment cool qui fonctionne le mieux pour ce problème spécifique? Ensuite, vous venez de créer les modèles de conception . Si vous êtes une créature vivante, il n'y a pas d'autre moyen de contourner; Même les animaux suivent les meilleures pratiques et les modèles de conception dans leur vie quotidienne.

Ne réinventez pas un marteau, mais ne traitez pas tous les problèmes comme un clou

Les modèles de programmation sont un grand gain de temps, car ils vous offrent des solutions prêtes à l'emploi, bien documentées et testées avec des cas moyens que vous pourriez facilement oublier. Mais vous devez apprendre (et réfléchir) quand les utiliser.

En paraphrasant votre question: est- ce qu'apprendre à conduire me ferait avancer plus vite ou marcherais plus lentement?

Apprendre à utiliser le modèle de programmation ne signifie pas que vous ne devriez pas vous entraîner à trouver vos propres solutions. Il y aura toujours suffisamment de problèmes pour exercer votre créativité. Connaître les modèles de programmation ne vous permettra de résoudre rapidement les problèmes connus et de vous concentrer sur ceux qui sont moins triviaux.

Revenons à la deuxième partie de votre question - votre professeur a-t-il raison?

Oui, il a raison . L'objectif principal des études est d' apprendre aux élèves à réfléchir . Ils doivent essayer de trouver leurs propres solutions au problème, puis les confronter aux solutions existantes. Ce n'est qu'ainsi qu'ils peuvent vraiment les comprendre. Si vous leur apprenez les schémas en premier, vous risquez qu'ils n'apprennent que mécaniquement à les appliquer et à ne pas comprendre ce qui se cache derrière.

C'est la raison pour laquelle vous apprenez d'abord aux étudiants à programmer, et les modèles sont introduits dans d'autres semestres.

Je déconseille absolument l'enseignement de la programmation en enseignant des modèles de conception. Vous ne pouvez pas bien les appliquer sans comprendre les principes qui les sous-tendent, il est donc beaucoup plus important d'enseigner ces principes.

J'ai tendance à penser que les modèles de conception ne sont pas vraiment très utiles non plus pour les programmeurs qui travaillent, de toute façon. Si vous comprenez parfaitement les principes impliqués dans un modèle de conception donné, dans une situation où c'est une bonne solution, vous aurez naturellement tendance à le construire (ou quelque chose de similaire) de toute façon, bien sûr, même si vous ne le saviez pas que c'était un modèle avec un nom. Quel que soit le temps que vous passeriez à apprendre, il vaut mieux apprendre à penser au code en général. Si vos compétences en "résolution de problèmes en général" ne sont pas à la hauteur, vous ne pouvez pas écrire un bon code, peu importe votre capacité à appliquer un ensemble de modèles. Et si vos compétences en «résolution de problèmes en général» sont bonnes, vous pouvez résoudre des problèmes même si vous ne connaissez pas un seul modèle.

Je pense aussi que dans un monde idéal , il n'y aurait pas être des modèles de conception, parce que les idées assez commun à appeler un modèle tout serait bien mis en œuvre dans les bibliothèques et nous aimerions effectivement réutilise le code au lieu de constamment réécrire il. Imaginez s'il y avait un «modèle de conception d'expression régulière», qui vous obligeait à implémenter un petit moteur d'expression régulière à chaque fois que vous vouliez l'utiliser. Les modèles de conception ne sont que des bibliothèques qui ne peuvent pas être écrites car le langage ne fournit pas les bonnes installations d'abstraction.

C'est en fait une autre raison de ne pas trop se soucier d'eux. ils ne sont pas du tout aussi universels qu'on le prétend parfois, mais sont en fait très fortement liés aux façons particulières de structurer les programmes qu'une langue particulière permet / encourage. Un livre de modèles de conception écrit pour Python serait complètement différent d'un livre écrit pour Java, et encore plus différent d'un livre écrit pour un langage non impératif comme Haskell. Mieux vaut comprendre à un niveau plus profond, et vous pourrez découvrir les modèles de conception vous-même dans n'importe quelle langue que vous maîtrisez.

Le commerce et l'éducation ont des objectifs différents. Si j'enseignais aux élèves des modèles de conception, j'adopterais la même approche. Mais dans un environnement de production, le temps et l'efficacité sont tout.

De plus, la (macro) économie en dehors de la classe est une chose différente. Voyez-vous les gouvernements dire: "Whoa! Maintenant, nous sommes super ennuyés de faire les impôts et de la même manière, alors essayons quelque chose de super farfelu cette fois"? Non, vous ne le faites pas, car de telles expériences sauvages peuvent briser l'économie au-delà de toute réparation. Au lieu de cela, ils ont tendance à s'en tenir à des approches éprouvées: augmenter le taux d'intérêt, annoncer des congés fiscaux, etc. En d'autres termes, ils s'appuient sur des modèles de conception.

La réponse est, bien sûr: oui.

Les modèles de conception sont un merveilleux outil d'apprentissage en soi, à condition de prendre le temps de comprendre comment ils fonctionnent et pourquoi ils apportent la valeur qu'ils apportent.

Ils peuvent également améliorer considérablement la productivité en accélérant le processus de conception, car ils fournissent des solutions familières aux problèmes qui surviennent tout le temps.

Cependant, s'ils court-circuitent trop la conception ou si les gens deviennent dogmatiques et trop précis quant à leur utilisation, ils ont l'effet inverse.

Les modèles de conception sont bien sûr moins créatifs. Voilà toute l'idée. La créativité est une ressource rare. Vous ne devriez pas le gaspiller sur des problèmes qui n'ont pas besoin de créativité. C'est beaucoup plus facile, plus rapide et plus susceptible de fonctionner si vous résolvez un problème de la même manière que des centaines de développeurs avant vous. Un code ennuyeux et peu passionnant qui fait son travail est en fait bon.