Comment savez-vous quand utiliser des modèles de conception?

Tout le monde peut lire le livre GoF pour savoir quels sont les modèles de conception et comment les utiliser, mais quel est le processus à suivre pour déterminer si un modèle de conception résout un problème? La connaissance du motif détermine-t-elle le design ou existe-t-il un moyen de comprendre comment un motif peut être utilisé pour modifier un dessin?

En d’autres termes, existe-t-il des modèles pour les modèles?

Les modèles de conception sont supposés fournir une structure dans laquelle les problèmes peuvent être résolus. Lorsque vous résolvez un problème réel, vous devez tenir compte de nombreuses variations minuscules de la solution à ce problème pour voir si certaines correspondent à un modèle de conception. En particulier, vous aurez probablement besoin de généraliser votre problème ou sa solution afin de créer un modèle de conception.

La réponse est que c’est un art. Connaître les modèles de conception est certainement une étape importante. Une façon de s’y habituer est d’étudier les applications des modèles de conception, pas seulement les modèles. Le fait de voir de nombreuses applications différentes d’un même motif peut vous aider à mieux adapter une tâche à un motif.

Je vous recommande fortement de lire Head First Design Patterns de O’Reilly. Cela explique comment ces modèles peuvent être utilisés dans le monde réel.

Head First Design Patterns

J’appendais aussi que n’essayez pas trop le design avec des motifs en tête. De plus, recherchez les “odeurs de code” qu’un motif peut aider à résoudre.

Remettez la question à plus tard: le modèle que vous devriez créer est “quel modèle correspond à mon problème”. Considérons un modèle vraiment simple, en trouvant un élément dans un tableau. en C, c’est quelque chose comme

TYPE_t ary[SIZE] = // ... gets initialized somehow size_t ix ; // Your index variable for(ix=0; ix < SIZE; ix++){ if (ary[ix] == item) { return ix ; } } 

Vous ne regardez pas le code et ne pensez pas "où puis-je l'utiliser", vous examinez le problème et dites "est-ce que je sais comment trouver un élément dans un tableau?"

Avec des motifs plus étendus, cela fonctionne vraiment de la même manière. Vous devez avoir beaucoup de copies d'une structure de données qui ne change pas souvent - ce qui vous fait penser à "Flyweight". Vous voulez quelque chose qui vit des deux côtés d'une limite de réseau, vous pensez Proxy.

Lorsque vous étudiez les patrons, en particulier le GoF, demandez-vous "quelles situations appellent ce modèle? Ai-je déjà vu ce schéma? Pourquoi aurais-je pu l'utiliser pour un travail précédent? Où puis-je trouver un exemple dans ma vie? "

Il y a un concept fondamental qui sous-tend les schémas que la plupart des gens ne comprennent pas. Ne les considérez pas comme des structures de données ou des algorithmes.

Au lieu de cela, pensez à votre code comme à des personnes qui envoient des messages, comme passer des notes ou envoyer des lettres, l’un à l’autre. Chaque object est une “personne”.

La façon dont vous organisez les «personnes» et les modèles qu’elles utilisent pour envoyer des messages sont les schémas.

Modèles de conception? Vous y trempez!

Il n’y a rien de spécial dans les modèles de conception, ce sont simplement des modèles de design. Tout le développement utilise des modèles de conception. Il y a un certain ensemble de modèles de conception dans la programmation orientée object qui sont considérés généralement souhaitables et sont devenus les modèles de conception canoniques. Mais il existe également de nombreux motifs de conception indésirables ou indifférents (tels que des anti-modèles de conception ) ainsi que des motifs non découverts et / ou non documentés.

Vous ne pouvez pas éviter d’utiliser des patterns lors de la programmation. Mais vous pouvez devenir plus conscient des modèles que vous utilisez et à quel moment certains modèles sont utiles et quand ils ne le sont pas. Étudier les schémas de conception canoniques à partir du livre GoF vous aidera, tout comme vous en apprendrez davantage sur les odeurs de code et le refactoring . Il n’y a pas de bonne réponse pour savoir quand un modèle ou un modèle de conception particulier doit être utilisé, vous devez acquérir de l’expérience en les utilisant et les implémenter afin de savoir quand et où utiliser ce modèle.

Expérience. Apprenez les modèles et les exemples réels de leurs utilisations. Chaque fois que vous avez une décision de conception à prendre, pensez à un modèle que vous connaissez. Au fil du temps, vous vous améliorez et vous découvrez de nouvelles façons d’appliquer les modèles à un plus large éventail de problèmes.

Un autre grand livre que j’ai trouvé était:

Refactoring aux Patterns

En montrant quand, où et comment vous pouvez modifier le code existant en modèles, cela m’a donné une bien meilleure compréhension des concepts et une capacité à identifier où ils peuvent être utilisés.

Rian van der Merwe a écrit un excellent article à ce sujet pour Smashing Magazine en juin 2012. Voici quelques points saillants.

Les modèles de conception sont utiles pour deux raisons:

  1. Les patterns permettent de gagner du temps car nous n’avons pas à résoudre un problème déjà résolu.
  2. Les modèles rendent le Web plus facile à utiliser, car, au fur et à mesure de l’adoption par les concepteurs, les utilisateurs s’habituent à la façon dont les choses fonctionnent, ce qui réduit leur charge cognitive lorsqu’ils rencontrent des éléments de conception communs.

van der Merwe recommande d’envisager de briser les modèles lorsque:

  1. La nouvelle manière améliore empiriquement la convivialité, ou
  2. La voie établie devient obsolète.

Comment avez-vous appris à utiliser une instruction if?

Je compare cela à cela parce que c’est un concept plus large dont vous devez connaître les tenants et les aboutissants avant de pouvoir l’utiliser efficacement. Une instruction if résout une classe de problèmes nécessitant un twigment. Un modèle de pont résout une classe de problèmes. Je ne les vois vraiment pas différemment.

Si vous connaissez les modèles, ils deviennent des outils dans votre boîte à outils. Lorsque vous examinez une tâche, vous sélectionnez parmi vos outils. À ce stade, vous devriez avoir une bonne idée de quel outil convient le mieux à un problème donné. C’est là que les formules cessent de fonctionner et que vous effectuez réellement des travaux d’ingénierie.

Je suis d’accord pour dire que l’apprentissage des modèles ne suffit pas. Le problème avec la plupart des livres est qu’ils ne fournissent pas d’exemples concrets. J’ai entendu dire que Head First Design Patterns, comme certains l’ont suggéré plus tôt, est un bon.

Une autre chose est que la plupart des livres ne sont intentionnellement pas spécifiques à la langue , ce qui peut être une bonne ou une mauvaise chose pour vous. Si important soit-il de comprendre un schéma en général, il est tout aussi important de bien le mettre en œuvre . Je suis tombé sur un livre intitulé C # 3.0 Design Patterns qui consacre à peu près autant d’encre à ces deux aspects indissociables.

J’ai eu la même question lorsque j’ai rencontré pour la première fois des motifs de conception. J’ai apprécié les concepts, mais je ne savais pas quand et comment les appliquer. Mon approche initiale consistait à rechercher l’applicabilité pendant la phase de conception. Une fois que vous avez un diagramme et des responsabilités semi-claires pour chaque bloc, il n’est pas trop difficile de prendre les responsabilités et de les recouper avec un livre de référence décent. Plusieurs bons ont été mentionnés ici, mais le GoF devrait être sur votre liste. L’étape suivante consiste à rechercher des améliorations dans la conception en fonction de ce que vous voyez dans les modèles.

Le concept d’un modèle de conception a été emprunté à l’ingénierie structurelle, tout comme de nombreuses pratiques en génie logiciel. Si vous envisagez de construire une structure, il faut prendre des décisions sur la manière de construire cette structure pour atteindre les objectives fixés. Lorsque vous prenez ces décisions, vous devez définir un ensemble d’exigences. Il peut s’agir de quelque chose d’aussi simple que Bridge doit pouvoir supporter X tonnes à la fois ou avoir une résistance à la traction particulière pour permettre suffisamment de mouvement dans le vent, etc. Un architecte utilisera ses connaissances antérieures pour réaliser ces choix de conception. Il / Elle serait très peu probable d’essayer de résoudre le problème à partir de zéro.

Le génie logiciel et les modèles de conception sont exactement les mêmes. Ce ne sont que des solutions communes à des problèmes communs. Si vous connaissez les modèles de conception, lorsque vous travaillez sur une conception et que certaines parties d’un système requièrent quelque chose qui corresponde à un modèle de conception, utilisez-le. N’essayez pas de placer un système autour d’un motif, ajustez les motifs de conception à votre système (là où ils conviennent). Essayez simplement de les considérer comme un ensemble de solutions pour réduire la quantité de travail de conception que vous devez effectuer, et soyez prudent de ne pas trop concevoir vos solutions pour intégrer autant de modèles de conception que possible. Cela ne servira qu’à rendre votre solution impossible à maintenir et probablement très difficile.

Un modèle de conception est une description générique sur la façon de résoudre un problème commun . Il y a 2 choses auxquelles nous devons faire attention:

Tout d’abord, il s’agit d’une description générique ; ce n’est pas la solution concrète, et ce n’est pas une recette complète non plus, c’est juste une description de la façon dont la solution devrait ressembler à un problème commun.

Deuxièmement, le problème est que la question est un problème commun: cela signifie que ce problème a été rencontré plusieurs fois avant et au fil du temps, les gens ont développé une description de la façon dont une solution idéale peut être appliquée à ce problème fréquemment répété.

Donc, si vous rencontrez un nouveau problème qui n’est pas courant, essayez de ne pas utiliser des modèles de conception pour le résoudre, ou du moins, ne faites pas de vos modèles de conception des outils pour résoudre tout type de problème.