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
