Comment étudier les modèles de conception?
J'ai lu environ 4 ou 5 livres sur les modèles de conception, mais je ne pense toujours pas avoir atteint un niveau intermédiaire dans les modèles de conception.
Comment dois-je aller étudier les modèles de conception?
Y at-il un bon livre pour les modèles de conception?
Je sais que cela ne viendra qu'avec l'expérience, mais il doit y avoir un moyen de les maîtriser?
Le meilleur moyen est de commencer à coder avec eux. Les motifs de conception sont un concept génial qui est difficile à appliquer simplement en les lisant. Prenez quelques exemples d'implémentations que vous trouvez en ligne et construisez autour d'eux.
Une excellente ressource est la page Data & Object Factory . Ils passent en revue les modèles et vous donnent des exemples conceptuels et réels. Leur matériel de référence est également excellent.
J'ai lu trois livres et je ne comprenais toujours pas très bien les motifs jusqu'à ce que je lise Head First Design Patterns by OReilly. Ce livre m'a ouvert les yeux et m'a vraiment bien expliqué.
Mes deux centimes pour telle et vieille question
Certaines personnes ont déjà parlé de la pratique et de la refactorisation. Je crois que le bon ordre pour en apprendre davantage sur les modèles est le suivant:
- Apprendre le développement piloté par les tests (TDD)
- Apprendre le refactoring
- Apprendre des modèles
La plupart des gens ignorent 1, beaucoup pensent qu’ils peuvent faire 2 et presque tout le monde y va droit pour 3.
Pour moi, la clé pour améliorer mes compétences en logiciel consistait à apprendre le TDD. C’est peut-être une longue période de codage lent et pénible, mais écrire vos tests en premier vous fait certainement beaucoup réfléchir à votre code. Si une classe a besoin de trop de passe-partout ou casse facilement, vous commencez à remarquer les mauvaises odeurs assez rapidement
Le principal avantage de TDD est que vous ne craignez plus de refactoriser votre code et vous oblige à écrire des classes hautement indépendantes et cohérentes. Sans une bonne série de tests, il est trop pénible de toucher quelque chose qui ne soit pas cassé. Avec le filet de sécurité, vous vous aventurez vraiment dans des changements radicaux de votre code. C'est le moment où vous pouvez vraiment commencer à apprendre de la pratique.
Vient maintenant le moment où vous devez lire des livres sur les modèles, et à mon avis, c’est une perte de temps totale que d’essayer trop dur. J'ai seulement très bien compris les modèles après avoir remarqué que j'avais fait quelque chose de similaire ou que je pouvais l'appliquer au code existant. Sans les tests de sécurité, ou les habitudes de refactoring, j'aurais attendu un nouveau projet. Le problème de l'utilisation de modèles dans un nouveau projet est que vous ne voyez pas en quoi ils affectent ou modifient un code fonctionnel. Je ne comprenais un modèle de logiciel que lorsque je modifiais mon code dans l'un d'entre eux, jamais lorsque j'en introduisais un nouveau dans mon code.
Derek Banas a réalisé des tutoriels youtube pour concevoir des motifs qui me plaisent beaucoup:
http://www.youtube.com/playlist?list=PLF206E906175C7E07
Ils peuvent être un peu courts dans le temps, mais son timing et sa présentation les rendent très agréables à apprendre.
Pratique, pratique, pratique.
Vous pouvez en apprendre davantage sur le fait de jouer du violoncelle pendant des années sans toujours être en mesure de jouer de l'archet pour créer un instrument qui ressemble à de la musique.
Les modèles de conception sont mieux reconnus comme un problème de haut niveau; un qui ne soit pertinent que si vous avez l'expérience nécessaire pour les reconnaître comme utiles. C'est bien que vous reconnaissiez leur utilité, mais à moins que vous ne voyiez des situations où elles s'appliqueraient, ou l'ont fait, il est presque impossible de comprendre leur vraie valeur.
Ils deviennent utiles lorsque vous reconnaissez des modèles de conception dans le code d'autrui ou un problème de la phase de conception qui correspond bien à un modèle; et ensuite examiner le modèle formel, examiner le problème et déterminer ce qu'est le delta entre eux et ce que cela dit à la fois sur le modèle et sur le problème.
C'est vraiment la même chose que le codage; K & R est peut-être la "bible" de C, mais sa lecture à plusieurs reprises ne donne pas une expérience pratique. il n'y a pas de remplacement pour l'expérience.
Pratique pratique pratique. Je pense que 4 à 5 livres est même un exercice de lecture excessif sans une bonne quantité de pratique. Je crois que le meilleur moyen de le faire est de commencer refactoriser vos projets en cours en utilisant les modèles. Ou si vous n'avez pas de projet sur lequel vous travaillez activement, alors faites-le à votre façon, puis essayez de refactoriser des motifs.
Vous ne pouvez pas les apprécier pleinement si vous n'avez pas souffert des problèmes qu'ils résolvent. Et gardez bien à l’esprit qu’il ne s’agit pas de balles en argent. Vous n’avez pas besoin de les mémoriser et de les appliquer difficilement à la volée. Mes deux centimes..
Posez-vous ces questions:
Que font-ils?
Qu'est-ce qu'ils découplent/couple?
Quand devriez-vous les utiliser?
Quand ne devriez-vous pas les utiliser?
Quelle caractéristique linguistique manquante les ferait partir?
Quelle dette technique contractez-vous en l'utilisant?
Y a-t-il un moyen plus simple de faire le travail?
J'ai trouvé qu'il est un peu difficile de comprendre ou de comprendre les avantages de certains schémas tant que l'un ne comprend pas les problèmes qu'ils résolvent et l'autre (pire) les moyens de les résoudre.
Hormis les livres GOF et POSA, je n’en ai pas vraiment lu, je ne peux donc pas vous donner d’autres recommandations. En réalité, vous devez simplement comprendre les problèmes et je pense que de nombreux développeurs moins expérimentés ne seront peut-être pas en mesure d’apprécier les avantages des modèles. Ce n'est pas léger contre eux. Il est beaucoup plus facile d’embrasser, de comprendre et d’apprécier les bonnes solutions lorsque l’on doit d’abord se débattre avec des alternatives médiocres.
Bonne chance
Beaucoup de bons exemples ont été donnés. J'aimerais en ajouter un:
Mal les appliquer. Vous n'avez pas besoin de le faire intentionnellement, cela se produira lorsque vous essayez de les appliquer dans votre ajustement Design-Pattern-fit initial. Pendant ce temps, chaque problème que vous verrez semblera correspondre exactement à un modèle de conception. Souvent, les problèmes semblent tous correspondre au même modèle pour une raison quelconque (Singelton en est le principal candidat).
Et vous appliquerez le motif et ce sera bien. Et quelques mois plus tard, vous devrez modifier quelque chose dans le code et vous rendre compte que l’utilisation de ce modèle particulier n’était pas aussi intelligente, car vous vous encodiez dans un coin et vous deviez à nouveau refactoriser.
Certes, ce n'est pas vraiment une réponse à faire et à apprendre en 21 jours, mais d'après mon expérience, c'est la plus susceptible de vous donner un bon aperçu de la question.
Avez-vous lu "Design Patterns Explained", par Allan Shalloway.
Ce livre est très différent des autres modèles de modèles de conception car il ne s'agit pas vraiment d'un catalogue de modèles, mais présente principalement un moyen de décomposer un espace de problème facilement mappé à des modèles.
Les problèmes peuvent être décomposés en deux parties: les choses communes et les choses qui varient. Une fois que cela est fait, nous mappons les éléments communs sur une interface et les éléments qui varient d’une implémentation à une autre. Essentiellement, de nombreux modèles entrent dans ce "modèle".
Par exemple, dans le modèle de stratégie, les éléments communs sont exprimés en tant que contexte de la stratégie et les parties variables en tant que stratégies concrètes.
J’ai trouvé ce livre extrêmement provocant, contrairement à d’autres modèles de livres qui, pour moi, ont le même enthousiasme que la lecture d’un annuaire téléphonique.
Avez-vous essayé le livre Gang of Four?
Modèles de conception: éléments d'un logiciel orienté objet réutilisable
Pour les livres, je recommanderais Modèles de conception expliqués , et Modèles de conception Head First . Pour vraiment apprendre ces modèles, vous devriez regarder votre code existant. Recherchez les motifs que vous utilisez déjà. Regardez code sent et quels motifs pourraient les résoudre.
J'ai dirigé quelques groupes de discussion sur les modèles de conception ( notre site ) et j'ai lu 5 ou 6 livres de modèles. Je recommande de commencer avec le livre Head First Design Patterns et d'assister ou de démarrer un groupe de discussion. Le livre Head First peut paraître un peu Hasboro au début, mais la plupart des gens l’aiment bien après avoir lu un chapitre ou deux.
Utilisez la ressource exceptionnelle - Guide d’apprentissage de modèles de conception de Joshua Kereivisky pour l’ordre des modèles et pour aider votre groupe de discussion. Par expérience, le changement que je préconise pour la commande consiste à donner la priorité à la stratégie. La plupart des développeurs d'aujourd'hui ont expérimenté une incarnation bonne ou mauvaise d'une Factory. Commencer par Factory peut donc entraîner beaucoup de discussions et de confusion sur le motif. première rencontre.
Je recommande HeadFirst DesignPattern. Lire le livre ne suffit pas, après avoir assimilé les concepts, vous devez trouver les réponses, car de nombreuses questions se posent dans votre esprit et essayer de découvrir les applications réelles de la vie dans lesquelles ces modèles peuvent être utilisés. Je fais de même et j'ai commencé à poser des questions, même si ces questions ont l'air ridicules.
La notion selon laquelle lire les modèles de conception et s’entraîner à les coder ne va pas vraiment aider l’OMI. Lorsque vous lisez ces livres 1. Recherchez le problème de base qu'un modèle de conception résout, commencer par créer des modèles est votre meilleur choix. 2. Je suis sûr que vous avez écrit du code dans le passé, analysez si vous rencontrez les mêmes problèmes que les modèles de conception visent à fournir une solution. 3. Essayez de refaire la conception/re-factoriser le code ou peut-être recommencer à zéro.
A propos des ressources que vous pouvez vérifier ces
- www.dofactory.com
- Modèles de conception: éléments d'un logiciel orienté objet réutilisable (Série Addison-Wesley Professional Computing) d'Erich Gamma, Richard Helm, Ralph Johnson et John M. Vlissides
- Modèles d'architecture d'application d'entreprise par Martin Fowler
1 est un point de départ rapide, 2 fera l’objet d’une étude approfondie. 3 vous expliquera ou devrait vous faire penser ce que vous avez appris dans 2 correspond à un logiciel d’entreprise.
Mes 2 centimes ...
Ma suggestion serait une combinaison d’en implémenter quelques-unes et d’en analyser quelques implémentations. Par exemple, dans .Net, il existe des utilisations de modèles d'adaptateur si vous examinez les adaptateurs de données, ainsi que quelques autres si vous creusez un peu dans le cadre.
Je ne connais pas le meilleur livre, mais les puristes pourraient dire: Modèles de conception: éléments d'un logiciel orienté objet réutilisable
En ce qui concerne mon favori personnel, j'aime bien Head First Design Patterns publié par O'Reilly. C'est écrit d'une voix conversationnelle qui m'attire. Lorsque je l'ai lu, j'ai examiné mon code source en même temps pour voir s'il s'appliquait à ce que je lisais. Si c'était le cas, je refacturais. C'est ainsi que j'ai appris la chaîne de responsabilité.
Pratique - Pratique - Pratique.
Les modèles de conception ne sont que des outils - un peu comme des fonctions de bibliothèque. Si vous savez qu'ils sont présents et qu'ils ont une fonction approximative, vous pouvez les extraire d'un livre à la demande.
Il n’ya rien de magique dans les modèles de conception, et tout bon programmeur en a déduit 90% avant l’apparition de livres. Pour la plupart, j'estime que les livres sont particulièrement utiles pour définir simplement les noms des divers modèles afin de pouvoir en discuter plus facilement.
J'ai appris les modèles de conception en écrivant beaucoup de logiciels vraiment terribles. Quand j'avais environ 12 ans, je n'ai aucune idée de ce qui était bon ou mauvais. Je viens d'écrire des piles de code spaghetti. Au cours des 10 prochaines années environ, j'ai appris de mes erreurs. J'ai découvert ce qui fonctionnait et ce qui ne fonctionnait pas. J'ai indépendamment inventé la plupart des modèles de conception courants. Ainsi, lorsque j'ai entendu parler de ces modèles, j'étais très enthousiaste à l'idée de les connaître, puis très déçue qu'il s'agisse simplement d'une collection de noms de choses que je connaissais déjà intuitivement. (cette blague sur apprendre soi-même le C++ dans 10 ans n'est pas une blague)
Morale de l'histoire: écrivez beaucoup de code. Comme d’autres l’ont dit, pratique, pratique, pratique. Je pense que tant que vous ne comprendrez pas pourquoi votre conception actuelle est mauvaise et que vous cherchez une meilleure solution, vous ne saurez pas vraiment où appliquer différents modèles de conception. Les modèles de conception devraient vous fournir une solution raffinée et une terminologie commune pour en discuter avec d'autres développeurs, et non une solution intégrée à un problème que vous ne comprenez pas.
Pour un débutant, les modèles Head First Design conviendraient, une fois que nous sommes familiarisés avec tous les modèles, nous essayons ensuite de visualiser les objets en temps réel dans ces modèles.
Ce livre vous aidera à comprendre les concepts de base, à moins que vous ne puissiez être MAÎTRE des MOTIFS DE CONCEPTION tant que vous n’avez pas implémenté le monde réel.
Je pense qu’il est également difficile d’étudier les modèles de conception. Vous devez en savoir plus sur OOP et sur certaines expériences de développement d'applications de moyenne à grande taille. Pour moi, j'étudie en tant que groupe de développeurs pour faire de la discussion. Nous suivons Guide d'apprentissage pour la conception de modèles qu'ils ont terminé l'étude des modèles. Il existe des développeurs C # et JavaScript réunis. Pour moi, c’est fantastique, le développeur C # écrit des codes en JavaScript et le développeur JavaScript fait la même chose pour les codes C #. Après avoir quitté une réunion, je fais aussi des recherches et lis quelques livres à la maison pour les relire. La meilleure façon de comprendre davantage et de garder à l’esprit mes pensées consiste à bloguer avec des exemples en C # et en JavaScript ici http://tech.wowkhmer.com/category/Design-Patterns.aspx .
Je suggèrerais d'abord avant de passer à chaque motif de conception, veuillez comprendre le nom de celui-ci. En outre, si quelqu'un connaît le concept, veuillez simplement expliquer et donner un exemple non seulement de programmation mais aussi dans le monde de la lecture.
par exemple:
Méthode d'usine:
Read world: Je donne juste de l’argent à 5, 10 ou 20 dollars et elle produira une pizza sans savoir quoi que ce soit, je viens d’obtenir une petite, moyenne ou grande pizza qui dépend de l’argent nécessaire pour pouvoir manger ou faire n'importe quoi.
Programmation: le client passe juste la valeur du paramètre $ 5, $ 10 ou $ 20 à la méthode usine et il retournera l'objet Pizza. Le client peut donc utiliser cet objet sans savoir comment il se traite.
Je ne suis pas sûr que cela puisse vous aider. Cela dépend du niveau de connaissance des personnes participant à la réunion.
Je pense que vous devez examiner certaines des difficultés que vous avez rencontrées en tant que développeur. Vous vous êtes tiré d'affilée après avoir révisé votre code pour la dixième fois en raison d'un autre changement de conception. Vous avez probablement une liste de projets pour lesquels vous avez ressenti beaucoup de retravail et de douleur.
À partir de cette liste, vous pouvez déduire les scénarios que les modèles de conception ont l'intention de résoudre. Avez-vous déjà eu besoin d'exécuter la même série d'actions sur différents ensembles de données? Devrez-vous pouvoir utiliser les futures capacités d'une application tout en évitant de retravailler toute votre logique pour les classes existantes? Commencez par ces scénarios et revenez au catalogue de modèles et à leurs problèmes respectifs qu’ils sont censés résoudre. Vous êtes susceptible de voir des correspondances entre le GoF et votre bibliothèque de projets.