Frustrations de modèle de conception

Question

Je suis un développeur ayant 4 ans d'expérience en codage .Net, et je ne me suis jamais beaucoup soucié des design patterns dans ma carrière. Récemment, j'ai été appelé à un entretien avec l'un des grands noms de l'informatique, j'ai passé 5 tours d'entretiens (résolution de problèmes, programmation en binôme, raisonnement logique, 2 tours d'entretiens techniques) et je n'ai pas été retenu pour le poste.

Les retours que j'ai reçus d'eux indiquent que je ne suis pas bon en matière de principes de design, bien qu'ils soient satisfaits de mes compétences techniques et de raisonnement logique. Cela m'a fait réfléchir : est-ce que connaître les design patterns est la seule façon de résoudre les problèmes ?

Bien que je n'ai jamais beaucoup utilisé de design patterns dans mon codage, j'ai toujours essayé d'implémenter les principes de base de POO :

• Principe ouvert/fermé (OCP)
• Inversion de dépendance (DI)
• Ségrégation d'interface
• Principe de substitution de Liskov (LSP)

Je pourrais utiliser ces principes pour concevoir un système qui soit faiblement couplé, ouvert aux améliorations et facile à maintenir. En fin de compte, ce sont les fondements de tous les design patterns.

Mais mon problème est de trouver le bon pattern pour le bon problème. Je sais que cette connaissance ne viendra pas simplement en lisant tous les livres publiés sur les design patterns et pratiques. Cette connaissance vient de l'expérience de la construction de différents systèmes.

Y a-t-il des cas d'utilisation disponibles pour la correspondance entre les patterns et les problèmes.. Et quelles sont vos suggestions pour apprendre les principes de design ?

Amicalement

Answer 1

Bien que je pense qu'il ne peut pas faire de mal de devenir plus familier avec les modèles de conception, je veux m'assurer qu'il n'y a pas de confusion dans votre question. Vous avez dit que le retour que vous avez reçu était que votre capacité à appliquer les principes de conception était faible, et vous en avez conclu que vous avez besoin d'étudier les modèles de conception. Mais c'est différent.

Un "modèle de conception" est un motif récurrent que vous voyez dans de nombreux domaines différents. Par exemple, en architecture, vous voyez le motif de "cour intérieure" dans de nombreux types de bâtiments différents. En programmation, vous voyez des modèles comme "une classe qui ne peut avoir qu'une seule instance" ou "un petit morceau de code qui assemble ceci à cela" dans de nombreux types de programmes différents.

Mais les principes ne sont pas des modèles. Un modèle est un type particulier de conception récurrente; un principe est une idée sous-jacente qui définit ce qui rend une conception bonne pour les utilisateurs de l'artefact en cours de conception.

Par exemple, un principe de conception du langage JScript est "être indulgent envers les petites erreurs". Si vous créez un objet date pour le 31 novembre, il corrigera silencieusement cela au 1er décembre au lieu de générer une erreur. Il n'y a pas de "modèle de tolérance aux petites erreurs". Rendre une conception tolérante aux erreurs est un principe de conception -- lorsque nous avons le choix de concevoir une fonctionnalité particulière, nous considérons dans quelle mesure elle s'aligne avec tous les principes -- certains étant contradictoires -- et les utilisons pour guider la conception de la fonctionnalité.

Ce n'est pas un principe de conception de C#; en fait, l'opposé est un principe de conception de C#. Les principes de conception ne sont ni bons ni mauvais en eux-mêmes; ce sont des lignes directrices pour ce qui rend une conception bonne pour son ensemble d'utilisateurs cible.

Écrire du code sans comprendre les modèles signifie ne pas avoir les outils dans votre boîte à outils qui rendent les tâches courantes plus faciles. Écrire du code sans comprendre les principes de conception signifie écrire du code qui est incohérent, difficile à comprendre et contraire aux besoins de ses utilisateurs. Les deux sont importants mais très différents.

Answer 2

Les design patterns sont appelés motifs parce qu'ils reviennent constamment dans de nombreux programmes indépendants, et non parce qu'ils sont utilisés pour assembler des programmes de la même manière que des carrés sont cousus ensemble pour faire une courtepointe. Ils peuvent aider à trouver une solution à un problème logiciel, mais ils ne constituent pas une solution en soi.

Answer 3

Même si vous utilisez C#, je vous suggère de parcourir certains livres sur les motifs. Le premier serait le livre GoF - Design Patterns. Ensuite, essayez de lire un livre sur les motifs de conception d'entreprise. En lisant, vous reconnaîtrez (ou verrez) le motif. Il s'agit généralement d'un moment "Aha".

Vous reconnaîtrez également la même chose dans votre propre code. Connaître les motifs vous aidera à bien concevoir. Cela aide à connaître les motifs car vous vous rappellerez immédiatement du motif lorsque survient un problème lié à celui-ci.

Les principes de programmation que vous avez spécifiés sont bons et SUIVEZ-LES. Cependant, ils sont plus au niveau de la classe. En remontant plus haut vers la conception du système, les motifs seront plus utiles.

Le plus important - Les motifs vous donnent un vocabulaire pour discuter des idées de conception avec toute l'équipe.

Answer 4

Je suis sûr que vous avez utilisé certains motifs de conception si vous programmez depuis 4 ans, même si vous n'êtes peut-être pas conscient que vous l'avez fait.

Les motifs de conception vous apprendront à résoudre certains problèmes pour lesquels quelqu'un est déjà passé et a trouvé une solution, puis l'a finalement documentée pour nous.

Si vous voulez apprendre les motifs de conception, vous pouvez commencer par "Head First Design Patterns", c'est un excellent livre.

Answer 5

Je ne suis pas sûr que ce dont vous avez vraiment besoin soit des modèles de conception. Vous avez probablement besoin d'une compréhension plus générale du design. Donner plus de conseils à ce sujet sera difficile sans plus d'informations.

Les design patterns (comme dans le style GoF) fonctionnent le mieux avec un style particulier d'écriture de code. Imaginez vos classes non pas comme des choses, mais comme des personnes. Imaginez ensuite que ces personnes communiquent entre elles, par quelque chose comme le passage de notes, ou par le biais du courrier interne ou quelque chose comme ça.

En général, les façons dont ces personnes communiquent, et les schémas de circulation des messages, sont assez proches des design patterns de GoF. Les patterns qui ne correspondent pas à cela sont généralement des 'helpers' nécessaires pour écrire des applications qui s'inscrivent dans ce modèle.