Est-il raisonnable de s'attendre à ce qu'un développeur senior sache quels sont les modèles de conception OOP? [fermé]


26

Je prépare des questions pour des entretiens d'embauche pour un poste de développement senior. Le travail comprendrait la conception orientée objet, et le logiciel existant utilise des modèles de conception, je voudrais donc demander aux candidats d'expliquer quelques modèles de conception qu'ils connaissent, qu'ils ont utilisés, comment ils les ont utilisés, pourquoi ils ont les a utilisés et ainsi de suite. Cependant, dans des interviews précédentes, lorsque j'ai demandé à des développeurs seniors ayant au moins 5 à 10 ans d'expérience sur les modèles de conception, presque personne n'en avait jamais entendu parler. Je pense que deux développeurs sur vingt pourraient nommer un seul modèle de conception (Singleton et MVC, respectivement).

Ma question est donc la suivante: est-il judicieux de poser ces questions? Ou est-ce un sujet tellement obscur que vous ne pouvez pas vous attendre à ce que les nouveaux employés les connaissent déjà?

Un développeur senior devrait-il avoir une expérience préalable avec les modèles de conception, ou diriez-vous que les modèles de conception sont un sujet si simple que tout développeur décent peut les reprendre pendant la formation? Si oui, quelles questions poseriez-vous à la place pour évaluer leurs capacités de conception?

Ajouter Après avoir lu les réponses jusqu'à présent, je devrais apporter quelques clarifications:

  • Le travail est pour un développeur .NET avec une expérience en OOP / OOD
  • Le code existant utilise des noms de classe comme IParameterGraphVisitoret IStorageFactorydans de nombreux endroits
  • Comment demandez-vous aux gens leurs expériences passées avec les designs OO qu'ils ont créés, s'ils n'ont pas le vocabulaire pour expliquer leurs designs? C'est ce que je veux faire, et tout ce que je peux trouver, c'est "veuillez dessiner la hiérarchie de conception / objet de votre dernier projet sur le tableau blanc".

27
Les motifs sont un artefact transitoire; c'est-à-dire qu'ils apparaissent à travers un bon design. Ils ne sont pas "utilisés". Il y a une raison pour laquelle le nom est "modèle" et non pas "contrainte" ou "exigence". Alors, voulez-vous quelqu'un avec une expérience de conception OO, ou quelqu'un avec une expérience de modèle de conception? Le premier est plus susceptible d'en savoir plus que les mots à la mode.
Michael K

6
@Michael: D'accord. Il y a une différence entre connaître les noms et pouvoir utiliser le modèle. J'ai été élevé sur OO, mais si vous me demandiez de nommer certains modèles et de les décrire, je ne ferais pas bien. Peu m'importe ce que l'industrie a décidé de l'appeler, mais je parie que j'ai en fait mis en œuvre la plupart des modèles que vous attendiez.
unholysampler

15
@Michael: J'ai toujours vu les modèles de conception comme une aide à la communication. Il est beaucoup plus efficace de dire "ceci est un visiteur d'arbre" au lieu de "ceci est une interface abstraite qui sera passée à une fonction qui parcourra un arbre et appellera une méthode via cette interface afin que je puisse séparer l'arborescence du code qui fait le travail réel ". Mais si vous connaissez de meilleures façons d'évaluer les compétences en conception dans une interview, veuillez répondre à la question! Voilà ce que je recherche.
nikie

3
Une meilleure approche serait peut-être de leur demander comment résoudre un problème spécifique. Pour ma part, je ne me souviens pas des noms de tous les modèles de conception, mais je sais comment les appliquer et les utiliser. comme le dit @Michael, avoir de l'expérience et connaître les mots à la mode sont deux choses différentes.
Tyanna

4
Une bonne connaissance des modèles de conception pourrait en fait être négative. Certains astronautes d'architecture ne parleront que de modèles de conception et les appliqueront avec vigueur, qu'ils aient ou non un sens.
William Pietri

Réponses:


67

Il y a de fortes chances qu'ils les connaissent. Ils ne les connaissent peut-être pas comme des «modèles de conception»; c'est-à-dire, ils peuvent ne pas être familiers avec la terminologie académique pour de telles choses. Ce que vous voyez comme une «machine d'état» pourrait simplement être une approche de bon sens à un problème pour un programmeur plus âgé et plus expérimenté. Je n'ai jamais prêté beaucoup d'attention aux `` modèles de conception '', par exemple, mais quand j'ai appris ce qu'était une State Machine, j'ai dû rire parce que je faisais ça depuis des années. Qui savait que j'étais un tel universitaire? Je l'ai toujours considéré comme une compétence de base en matière de codage, et non comme un «modèle de conception».

Le point n'est pas de supposer que vos développeurs expérimentés connaissent les termes du manuel pour les choses; demandez-leur plutôt comment ils structureraient les classes ou comment ils aborderaient une tâche.


2
+1 J'utilisais ces structures depuis un certain temps avant la sortie de Gang of Four, j'ai donc toujours du mal à me souvenir des noms qui leur ont été donnés.
dietbuddha

10
La littérature sur les modèles est, je pense, assez explicite sur ce genre de chose - les modèles ne sont pas destinés à remplacer le design, ils sont destinés à aider à communiquer sur le design. (Je dirais qu'aider à communiquer sur le design aide également le design lui-même, mais je suppose que c'est un point différent.)
Aidan Cully

5
+1. Cela m'arrive tout le temps. Il y a quelque temps, j'ai lu l'article wiki sur "L'injection de dépendance" pour découvrir pourquoi il semblait si populaire, seulement pour découvrir que c'était une technique que j'utilisais depuis des années, mais je ne lui ai jamais donné de nom. Idem avec "machine d'état".
whatsisname

4
N'est-ce pas une attente raisonnable pour un développeur senior de suivre ce qui se passe sur le terrain et d'adopter la terminologie largement utilisée? Les modèles existent depuis plus de 15 ans maintenant, vous ne pouvez même plus les appeler "nouveaux" ...
Péter Török

2
Le but des modèles de conception était de fournir un langage commun permettant aux développeurs de logiciels de se parler des solutions aux problèmes récurrents. C'est le point dans l'apprentissage des modèles de conception. OMI, cela montre un manque de dévouement à la profession pour qu'ils ne prennent même pas la peine d'apprendre quelque chose qui a été à la pointe du développement de logiciels OO au cours des 17 dernières années. J'aurais certainement des réserves sur quiconque ne peut pas nommer et comprendre certains modèles de base. Ne se soucient-ils pas de ne pas pouvoir comprendre les conversations des gens parce qu'ils ne connaissent pas les noms?
Dunk

25

Votre attente est tout à fait raisonnable pour un développeur OO senior. Quiconque se dit que sans connaître les modèles de conception démontre simplement que l'expérience ne s'apporte pas automatiquement au fil des années :-( Bien sûr, il y a beaucoup de développeurs qui ont passé des années voire des décennies sur le terrain, sans jamais entendre parler de design modèles - cela montre simplement qu'ils n'étaient pas intéressés à apprendre de nouvelles idées, à s'améliorer et à adopter les meilleures pratiques.

Un développeur senior devrait-il avoir une expérience préalable avec les modèles de conception, ou diriez-vous que les modèles de conception sont un sujet si simple que tout développeur décent peut les reprendre pendant la formation?

L'expérience de l'OMI compte beaucoup. En théorie, un développeur décent peut lire les modèles de conception dans un livre, ou même sur Wikipedia, et comprendre le concept de base en 15 minutes. Cependant, l' application correcte des concepts nécessite une expérience durement acquise. Il est facile de se passionner pour les motifs, en essayant de les entasser dans chaque morceau de code possible, l'art pour l'art. Il est également facile de les rejeter en disant que "les modèles ne sont pas une solution miracle, utilisez simplement la chose la plus simple qui pourrait éventuellement fonctionner". Trouver le juste milieu entre les deux extrêmes en apprenant quand et comment utiliser des modèles pour résoudre de vrais problèmes, et quand ne pas les utiliser, demande des années d'expérience .

Quelles questions poseriez-vous à la place pour évaluer leurs capacités de conception?

De concert avec ce qui précède, je voudrais seulement ajouter ces questions à votre liste:

  • Quels sont les inconvénients des modèles de conception (en général, et de ceux qu'ils mentionnent explicitement)?
  • Quand ne pas les utiliser et pourquoi?

Mise à jour

@GrandmasterB a un bon point en ce que certains développeurs peuvent utiliser des modèles de conception spécifiques sans connaître leur nom. D'une certaine manière, il a raison en ce qu'il s'agit d'une question de terminologie / communication. Cependant, l'autre côté de la médaille est qu'il s'agit bien d'une question de terminologie / communication :-) C'est-à-dire que l' un des principaux avantages des Design Patterns est de donner un vocabulaire commun aux développeurs, améliorant considérablement la communication . (Essayez d'expliquer l'idée de base de l' adaptateur sans utiliser le mot lui-même, ou ses synonymes "wrapper" et al!). Aussi talentueux et compétent qu'un candidat puisse être, sans connaître la ou les terminologies largement acceptées, il introduira un problème de communication dans votre équipe.


2
Je ne sais pas dans quelle mesure cela est généralement vrai, mais je dirais également que l'utilisation de modèles de conception peut entraîner des problèmes de communication. Par exemple, lorsque quelque chose que vous faites est similaire à un modèle bien connu, mais pas exactement comme lui, la connaissance du modèle existant peut masquer vos différences locales. Ou lorsque les développeurs de votre équipe ne comprennent pas complètement le modèle, ils peuvent utiliser le nom du modèle de manière idiosyncrasique.
Aidan Cully

1
@Aidan, bon point là-bas, bien que pour moi ce soit une mauvaise utilisation des modèles. C'est une autre façon dont l'expérience et la pratique sont indispensables, c'est-à-dire en différenciant les variantes du même modèle par rapport à deux modèles différents.
Péter Török

1
+1, toute personne se qualifiant de développeur .NET senior devrait être en mesure de nommer au moins quelques noms de modèle explicites et leur utilisation. C'est une question de communication et de boîte à outils, si rien d'autre.
techphoria414

Je l'ai lu 3 fois et je ne sais toujours pas si le premier paragraphe est
sarcastique

@briddums, qu'est-ce qui vous fait penser que c'est du sarcasme?
Péter Török

10

Un développeur senior ? Absolument. Un junior devrait. J'ai 15 ans, je n'ai pas d'éducation formelle sur le sujet et même je les comprends. Il est non seulement raisonnable de s'attendre à ce qu'ils les connaissent, mais ce serait inacceptable s'ils ne les connaissaient pas. En supposant qu'ils connaissent quelque chose sur la programmation orientée objet, ce qu'ils font très probablement.


14
Être juste. OO n'est devenu l'une des méthodologies dominantes au cours de votre vie. Il y a un certain nombre de personnes qui ont obtenu leur diplôme avant que Java ne soit le langage utilisé au collège. Il y a beaucoup de gens qui ne vivent pas dans le monde OO.
unholysampler

2
@unholysampler: bien sûr, mais je pense que c'est une position OOP dont on parle
Anto

1
@unholysampler: J'aimerais bien vivre à cette époque .. Je ne supporte pas de voir autre chose que Java à uni <_ <
poke

10

Dans une entrevue, vous devez demander ce qui est essentiel pour le candidat de savoir afin de faire le travail.

S'ils doivent connaître les noms des modèles car ils proviennent de Gang of Four, alors c'est une exigence valide.

Si, d'autre part, vous voulez qu'ils affichent une connaissance pratique appropriée de l'architecture du programme, je pense que vous feriez mieux de leur donner un problème et de leur demander comment cela structurerait le code. S'ils vous donnent la solution de modèle appropriée, vous avez la preuve qu'ils le savent, quel que soit le nom utilisé.

Chaque fois que j'interviewe pour des postes supérieurs, ils ont tendance à être plus «pratiques» que les questions et réponses. Je veux une démonstration claire de compétence et de confort dans la programmation. Je veux également une base solide dans les concepts CS, ce qui signifie des compétences plus générales sur la façon d'appliquer des concepts tels que l'encapsulation, les algorithmes, le couplage / la cohésion, etc. Expérience et familiarité dans plusieurs langages et paradigmes.


4

Dépend du domaine de leur expertise. Je ne m'attendrais pas à ce qu'un développeur C intégré en sache beaucoup sur les modèles de conception. Si nous parlons d'un développeur Java ou .NET, ils doivent être familiers avec les modèles de conception, et surtout comment ne pas trop s'emballer avec eux.


2
+1 pour ne pas trop s'emballer avec les patrons de design :)
Zaky German

Bon point. Ajout d'une clarification à la question. C'est pour le développeur .NET, avec une expérience de projet dans au moins le langage de programmation OO.
nikie

4

En supposant que vous recherchez l'ancienneté dans la POO, la réponse est définitivement oui. Les modèles de conception sont le lexique du langage OOP.

De plus, il est aujourd'hui déraisonnable qu'un programmeur OOP décent avec 10 ans d'expérience ne puisse pas nommer un modèle de conception, étant des modèles de conception largement adoptés dans les API, les bibliothèques et les cadres de développement standard.

Cela fait des années maintenant que je pose cette question lors des entretiens et c'est un showstopper lorsque le candidat n'apporte pas de réponses satisfaisantes sur le sujet.


3

Oui, mais vous devriez probablement obtenir leur compréhension en posant des questions de conception plutôt qu'en demandant aux gens d'énumérer les modèles de conception dont ils ont entendu parler. Je suis assez à l'aise avec les modèles décrits dans PoEAA, GoF et même certains modèles de programmation fonctionnelle et je ne pense toujours pas que vous en apprendrez beaucoup plus sur mon approche de la résolution des problèmes en me demandant de nommer certains modèles.

Étant donné une question comme "Concevez-moi un éditeur de texte" avec des suivis comme, "Comment allez-vous prendre en charge les objets intégrés comme les images? Gras et italique? Annuler?" Vous finirez probablement par en entendre suffisamment pour reconnaître le modèle de commande, le modèle composite, le modèle de souvenir et quelques autres, même avec une courte conversation.

Des modèles de conception ont été découverts puis décrits afin que nous ayons un langage commun avec lequel communiquer les décisions de conception.

J'ai malheureusement travaillé pour quelqu'un pour qui chaque utilisation d'un modèle de conception devait être expliquée et justifiée, non pas à cause d'une diligence raisonnable, mais parce qu'il ne les connaissait tout simplement pas. Ce n'est pas amusant. Mais les développeurs les plus sérieux ont, par accident ou par conception, appris les noms des modèles OO les plus couramment utilisés, si rien d'autre, et la plupart des développeurs d'applications d'entreprise dignes de ce nom connaissent au moins quelque chose sur les modèles PoEAA les plus courants.


3

Raisonnable. Certainement. Nécessaire. Non

Je demande aux candidats potentiels s'ils connaissent les modèles de conception. Ce n'est qu'un critère parmi d'autres à peser dans son ensemble. Ne négligez pas l'image totale.

Oui, de nombreux développeurs utilisent sans le savoir certains modèles de conception, sans aucun doute.

Ce n'est pas pourquoi je pose la question.

Il est important de savoir que je peux communiquer rapidement et efficacement avec un autre développeur. Je ne veux pas passer 20 minutes sur un tableau blanc expliquant une machine d'état pour constater qu'ils "l'ont utilisé auparavant, mais n'ont jamais su comment l'appeler". Ce n'est pas productif.

Ils aident également au processus de refactorisation. En parcourant le code, on peut implémenter au hasard une forme de modèle d'usine, mais le modèle d'usine GoF a résisté à l'épreuve du temps. C'est pourquoi c'est le modèle d'usine, pas ENCORE UN AUTRE fp (réinventer la roue n'est pas préférable, Joel sur le logiciel a beaucoup sur les inconvénients de le faire).

Une équipe qui utilise et reconnaît l'importance des modèles de conception augmente la communication et la productivité. Si votre équipe, en tant qu'unité, n'utilise pas de dp, elle perd sa pertinence.


2

Parlant de ma propre expérience, j'ai ignoré les modèles de conception pendant un bon moment. Je savais qu'ils existaient, je n'ai jamais lu à leur sujet. Une fois que j'ai finalement mordu la balle, j'ai réalisé que j'utilisais le modèle de conception depuis le début et je ne m'en rendais pas compte ou je ne savais pas que mes solutions de conception avaient en fait un nom commun.

Je serais plus enclin à proposer un ensemble de problèmes où un modèle de conception particulier correspond bien à la solution et à voir le développeur proposer quelque chose de similaire au modèle. S'ils le font, tant mieux. Je serais peut-être encore plus enclin à embaucher un développeur qui utilise des modèles de conception sans le savoir, car je vois de nombreux développeurs qui ont des connaissances en matière de modèles de conception essayer d'adapter une solution à un modèle lorsque cela n'est pas approprié plutôt que de réaliser qu'un modèle particulier arrive à résoudre le problème. problème bien.


2

Je pense qu'une meilleure question serait: étant donné le nom d'un motif et une description du motif, par exemple un motif d'usine du livre Gang of Four, le candidat devrait être en mesure de proposer un scénario où le motif serait une approche raisonnable.


1

Il y a des développeurs avec 5 à 10 ans d'expérience et des développeurs seniors. Ce n'est pas du tout la même chose. Oui, si vous embauchez à un niveau supérieur et que vous vous attendez à ce que les gens connaissent et utilisent les modèles de conception, je n'embaucherais pas de personne âgée qui ne les connaissait pas. Ce serait comme embaucher un spécialiste de base de données qui ne comprend pas les jointures gauches. C'est un truc assez basique pour un vrai développeur senior. J'embaucherais probablement une personne junior cependant.


1

Oui, en effet, ils devraient être familiers avec le terme, et devraient même être en mesure de nommer quelques-uns des modèles - mais ne faites pas l'erreur de confondre les connaissances théoriques avec l'expérience.

Il y a beaucoup de gens qui, avant une interview, réviseront les modèles de conception et pourront les expliquer avec une brève description - mais ce n'est que la théorie. C'est un vrai développeur senior qui peut repérer quand en utiliser un, ou sans connaissance d'un modèle formel résoudrait le problème d'une manière classique.

La meilleure façon de vérifier est de les laisser concevoir quelque chose devant vous et de poser des questions approfondies. Un développeur senior est quelqu'un qui peut penser naturellement au niveau de l'abstraction. Ce sont ces gens qui "créent" les modèles de conception.

Comme la classe Peopleware qui parle d' embaucher un jongleur sans leur demander de jongler - simplement parce qu'ils disent qu'ils ne peuvent pas signifier grand-chose ... essayez-les.


Pourriez-vous donner un exemple de problème? Tous les exemples de conception que je peux proposer sont soit si simples qu'aucune conception intéressante n'est nécessaire, soit tellement interprétés qu'il est difficile de voir pourquoi une solution serait meilleure qu'une autre, ou si complexes qu'ils ne peuvent pas être résolus dans une interview.
nikie

Peu importe ce que c'est, ce pourrait être quelque chose d'aussi simple que "Concevez-moi un jeu de tirage au sort". Attendez de voir ce qu'ils en font. Ajoutez ensuite une exigence pour explorer ce qui vous intéresse, par exemple: Comment pouvez-vous changer cela pour le rendre: testable | portable | utilisé comme service | utilisable pour différentes interfaces utilisateur | courir sur le web ... etc
Stephen Bailey

0

Comme je l'ai déjà dit, je pense aussi que c'est OK s'ils ne se souviennent pas des mots à la mode par cœur. Mais comme il s'agit d'un poste de niveau supérieur, ils devraient savoir quand appliquer un modèle pour résoudre un problème de manière optimale au lieu d'utiliser les pires solutions. Ainsi, donnez-leur un problème qui devrait être résolu à l'aide d'un modèle (par exemple, comment créer un objet sans coder en dur sa classe, comment accéder aux éléments d'un objet sans avoir de détails sur sa mise en œuvre, etc.) et voir comment ils l'attaqueront.


0

Certainement, ils devraient connaître les modèles, mais pas nécessairement les mots à la mode.

Par exemple, MVC a de nombreuses alternatives très similaires comme PAC, 3 niveaux. Il y a quelques années, un autre mot à la mode populaire pour MVC était "Model 2". En fait, je connais de très bons développeurs qui connaissent parfaitement ce modèle, mais je ne savais pas que le mot à la mode actuel était MVC.


0

Très simplement: si vous les utilisez, vous devez demander à vos candidats. S'ils connaissent des modèles, cela devrait ajouter quelques points positifs; mais ne pas savoir ne doit pas nécessairement les exclure, surtout s'ils montrent de bonnes compétences en OOD. Il est peu probable que les développeurs qui ont participé à des projets de maintenance en savent beaucoup sur les modèles de conception par rapport à ceux qui ont commencé à les concevoir. cela dépend aussi du fait que l'on leur a enseigné des modèles de conception à l'université. D'après mon expérience, il est peu probable qu'ils le fassent. La plupart des universités et des cours privés vous enseignent OOP mais pas OOD. Les chances qu'ils aient étudié le DP sont encore moindres.

Personnellement, je n'avais pas étudié le DP jusqu'à ce que mon projet me demande aussi. Même alors, j'ai constaté que j'avais utilisé quelques-uns des modèles, au moins d'une manière similaire, sinon de la manière exacte décrite dans le livre. J'ai été surpris de savoir qu'ils étaient codifiés. Recherchez donc de bonnes compétences en conception si elles ne connaissent pas DP. S'ils connaissent le DP, il est probable qu'ils sont bons en conception, mais qu'ils les testent toujours. Ils ont peut-être simplement entendu un mot à la mode sur DP ou découvert par un initié et ont juste étudié quelques modèles sans les avoir appliqués.


0

Il est raisonnable pour vous de vous attendre à ce que les personnes qui postulent pour un emploi avec vous sachent (ou apprennent) les choses dont vous avez besoin dans votre créneau, qu'elles soient ou non conformes aux normes de l'industrie. Sinon, vous vous condamnez à la médiocrité. Mais méfiez-vous de faire de certaines connaissances (ou compétences) une exigence d'emploi, si ce n'est pas vraiment nécessaire.

Disons que vous avez deux candidats avec des antécédents à peu près similaires, et l'un est en mesure de vous parler des modèles de conception, et l'autre ne l'est pas. Qu'est-ce que cela vous apprendra sur la façon dont ils vont fonctionner au travail?

Vous dites que le logiciel existant utilise des modèles de conception. Est-ce un avantage? Si c'est le cas, comment? Votre objectif est-il que les nouveaux logiciels écrits soient conformes aux modèles existants ou que de nouveaux modèles soient introduits? Pourquoi?


0

Je peux penser à un développeur senior qui ne connaît pas les modèles de conception dans la situation suivante:

  1. Il y a seulement un livre sur les modèles de conception. C'est le livre qui les a rendus populaires en premier lieu. Si la personne n'a pas lu ce livre, il est possible qu'elle ne connaisse pas les modèles de conception ou qu'elle en ait entendu parler, mais qu'elle ne sache pas à quoi elle sert
  2. Au lieu de cela, ils devraient savoir quelque chose comme uml ...
  3. Trouver de bonnes informations sur les modèles de conception sur Internet n'est pas facile. Vous êtes très chanceux si vous cliquez sur la bonne page Web qui possède une bonne connaissance des modèles de conception. Le simple fait de venir au logiciel après 1995 pourrait faire en sorte qu'une personne ne connaît pas le livre de modèles de conception, car le livre est ancien.

-2

Pourquoi un développeur dans un environnement non OO devrait-il connaître les modèles de conception OO? J'ai travaillé dans des magasins qui ne faisaient que du Cobol, uniquement du PL / SQL, seulement du Progress 4GL, etc. modèles.

Être capable de citer sans réfléchir à partir d'un catalogue de modèles ne fait pas non plus de vous un bon développeur (en fait, selon mon expérience, il produit certains des pires morceaux de code que j'ai jamais vus). C'est pourtant ce que vous attendez d'être la marque d'un "développeur senior". Je travaille l'industrie depuis 15 ans, mais ne me demandez pas de dessiner un schéma de configuration. Je ne lui ai jamais donné beaucoup de temps, je n'en ai pas besoin. J'ai acquis suffisamment d'expérience pour trouver ce qui fonctionne sans y mettre un nom spécifique, et si j'ai besoin de la définition formelle, je sais où le chercher (et oui, j'ai les livres de référence dans ma bibliothèque personnelle). C'est la marque du développeur expérimenté, et non pas les connaissances acquises par le bourrage de certains livres scolaires.


2
Je ne vois pas la pertinence de la question. Je n'interviewe pas pour un poste de développeur Cobol et je ne vais certainement pas demander aux gens de "citer inconsciemment des connaissances par cœur". Votre seul point semble être que vous ne connaissez pas les modèles de conception.
nikie

unix / linux est écrit en «C», il est plein de modèles OO, et bien plus que dans le livre de gof.
ctrl-alt-delor

2
"J'ai acquis suffisamment d'expérience pour trouver ce qui fonctionne sans y mettre un nom spécifique." Une partie de la valeur des modèles de conception EST le nom. Vous pouvez donc dire «utilisons un modèle d'usine» et votre collègue comprend immédiatement ce que vous voulez dire. Si vous savez tous les deux comment faire ce genre de chose, mais qu'aucun de vous n'a de nom pour cela, vous devez passer beaucoup plus de temps à expliquer avant que l'autre personne ne dise, "oh, CELA." Et encore une fois, si le code contient un WidgetFactory, quelqu'un qui connaît le modèle Factory comprend à quoi il sert.
Nathan Long

Je suis d'accord avec Nathan. Le point des modèles de conception est de mettre un nom à une solution commune. Il existe très peu de modèles de conception auxquels les gens n'auraient pas pensé seuls. L'avantage est d'attribuer un nom communément accepté afin que vous puissiez communiquer avec d'autres développeurs sans entrer dans les détails sanglants. Donc, votre opinion selon laquelle vous n'avez pas besoin de mettre un nom à un modèle parce que vous les utilisez déjà est similaire à votre affirmation selon laquelle la communication n'est pas importante. Essayez de passer une entrevue et faites la déclaration «la communication n'est pas importante» et voyez combien d'offres d'emploi vous obtenez.
Dunk
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.