Recommandé
Contenu connexe
Similaire à Un code maintenable avec le principe de responsabilite unique
Similaire à Un code maintenable avec le principe de responsabilite unique (17)
Un code maintenable avec le principe de responsabilite unique
- 1. Well-crafted software un code maintenable avec le principe de responsabilité unique Guillaume Gardais, Nicolas Capponi - Agile Grenoble 2012 1
- 2. Contrat de session 2 SOLID / GRASP Des solutions magiques Principe de Responsabilité Unique
- 3. Qui sommes nous ? 3 Kelkoo depuis 2010 Développeur Architecte logiciel @Wace99 Kelkoo depuis 2003 Développeur Architecte logiciel @ncapponi
- 4. Institut Médico Légal du Code 4 avec Nicolas dans le rôle du Docteur Robert « Uncle Bob » Martin Guillaume dans le rôle de l’Etudiant Codeur
- 5. Indices 5 Beaucoup de variables d'instances, de 1 méthodes, de lignes de codes, de classes Décrire la classe en une phrase: sans OU, 2 sans ET Nom de classe générique: Manager, Process, 3 Service, Helper, Tools Code dupliqué: responsabilité diluée entre 4 plusieurs éléments
- 7. Indices (suite) 7 5 Métrique : LCOM4 6 Métrique : complexité cyclomatique 7 Métrique : package cohésion
- 10. Solution: Diviser 10 1 1 classe pour 1 responsabilité
- 11. Solution: Facade 11 2 Simplifier l’utilisation de « Cart »
- 12. Solution: Interface 12 3 Séparer les responsabilités
- 13. Solution: Visiteur 13 4 Respecter l’encapsulation
- 14. Quelle solution choisir ? 14
- 15. Un peu de théorie 15 Principe de responsabilité unique (SRP) Une classe ne doit avoir qu’une seule raison de Robert Martin 1995/2002 changer Chaque responsabilité est un axe de changement
- 16. Conclusion 16 Contexte SRP est un principe, pas une règle
- 17. Merci 17 Code, références: https://github.com/ncapponi/srp-2012 @Wace99 @ncapponi
- 18. 18
- 20. Identifier les responsabilités 20 Product Architecte Marketing Rôle Familles de fonctions Ajouter Enlever Stockage Contenu du Un produit Un produit en BDD Sérialise Mail à envoyer Cart CartRepository MailBuider Module
- 21. Gestion du changement 21 Dégradation lors des évolutions Réévaluer les axes de changements à chaque évolution
- 22. Quelques concepts 22 Couplage: Rigidité: faire évoluer l’un sans chaine de dépendances modifier l'autre Fragilité : en touchant un module, on casse un comportement dans un autre modèle apparemment indépendant
Notes de l'éditeur
- Ce que vous verrez1Focus sur le principe de responsabilité unique (SRP)2 Indices pour détecter le non respect de RSP3 Approches pour respecter le SRP4 60% de code / 40% de slidesCe que vous ne verrez pasLes concepts SOLID, GRASPDes solutions magiques, des réponses toute faites
- Self presentation
- Institut médico-légal du codeEtudiant CodeurDocteur Robert « Uncled Bob » Martin
- Institut médico-légal du codeEtudiant CodeurDocteur Robert « Uncled Bob » Martin
- Institut médico-légal du codeEtudiant CodeurDocteur Robert « Uncled Bob » Martin
- Institut médico-légal du codeEtudiant CodeurDocteur Robert « Uncled Bob » Martin
- ++ implémentation séparée+ pas d’interface (inversion de dépendance) Client doit chercher quelle classe implémente quelle responsabilité- Couplage partiel entre classes d’implém.
- + implémentation séparée+ facilite utilisation par client Interface partage plusieursresponsabilités- Couplage partiel entre classes d’implémentation
- + chaque acteur a son interface Implémentation non séparée Client doit chercher quelle interface utiliser
- + implémentation séparée+ encapsulation préservée+ facilité d’ajout des fonctionnalités- couteux de changer la structure
- On a montré quelques solutions possibles pour respecter le SRPOn voit bien qu’il n’y pas de solution idéale.Quand ce sera à vous de faire un choix, il dépendra de votre contexteTout sera dans l’art du compromis.