Well-crafted softwareun code maintenable avec le principe de responsabilité                      unique     Guillaume Gard...
Contrat de session                                         2 SOLID / GRASP                                      Des soluti...
Qui sommes nous ?                    3               Kelkoo depuis 2010                 Développeur               Architec...
Institut Médico Légal du Code                              4                            avecNicolas dans le rôle du Docteu...
Indices                                                5          Beaucoup de variables dinstances, de  1       méthodes, ...
Indices (suite)                             7  5    Métrique : LCOM4  6    Métrique : complexité cyclomatique  7    Métriq...
Radiographie du cadavre   9
Solution: Diviser                    101   1 classe pour 1 responsabilité
Solution: Facade                           112   Simplifier l’utilisation de « Cart »
Solution: Interface                123    Séparer les responsabilités
Solution: Visiteur               134    Respecter l’encapsulation
Quelle solution choisir ?   14
Un peu de théorie                                        15                                  Principe de                  ...
Conclusion                      16                     Contexte      SRP est un principe,         pas une règle
Merci                                          17        Code, références:        https://github.com/ncapponi/srp-2012    ...
18
Identifier les responsabilités                                             20       Product              Architecte       ...
Gestion du changement                          21    Dégradation lors des        évolutions                       Réévalue...
Quelques concepts                                      22                                    Couplage:       Rigidité:    ...
Un code maintenable avec le principe de responsabilite unique
Un code maintenable avec le principe de responsabilite unique
Un code maintenable avec le principe de responsabilite unique
Upcoming SlideShare
Loading in …5
×

Un code maintenable avec le principe de responsabilite unique

1,207 views
1,112 views

Published on

Présentation Agile Grenoble 2012 - Nicolas Capponi & Guillaume Gardais

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,207
On SlideShare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
23
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide
  • 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.
  • Un code maintenable avec le principe de responsabilite unique

    1. 1. Well-crafted softwareun code maintenable avec le principe de responsabilité unique Guillaume Gardais, Nicolas Capponi - Agile Grenoble 2012 1
    2. 2. Contrat de session 2 SOLID / GRASP Des solutions magiques Principe de Responsabilité Unique
    3. 3. Qui sommes nous ? 3 Kelkoo depuis 2010 Développeur Architecte logiciel @Wace99 Kelkoo depuis 2003 Développeur Architecte logiciel @ncapponi
    4. 4. Institut Médico Légal du Code 4 avecNicolas dans le rôle du Docteur Robert « Uncle Bob » Martin Guillaume dans le rôle de l’Etudiant Codeur
    5. 5. Indices 5 Beaucoup de variables dinstances, 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
    6. 6. Indices (suite) 7 5 Métrique : LCOM4 6 Métrique : complexité cyclomatique 7 Métrique : package cohésion
    7. 7. Radiographie du cadavre 9
    8. 8. Solution: Diviser 101 1 classe pour 1 responsabilité
    9. 9. Solution: Facade 112 Simplifier l’utilisation de « Cart »
    10. 10. Solution: Interface 123 Séparer les responsabilités
    11. 11. Solution: Visiteur 134 Respecter l’encapsulation
    12. 12. Quelle solution choisir ? 14
    13. 13. 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
    14. 14. Conclusion 16 Contexte SRP est un principe, pas une règle
    15. 15. Merci 17 Code, références: https://github.com/ncapponi/srp-2012 @Wace99 @ncapponi
    16. 16. 18
    17. 17. Identifier les responsabilités 20 Product Architecte Marketing Rôle Familles de fonctionsAjouter Enlever Stockage Contenu duUn produit Un produit en BDD Sérialise Mail à envoyer Cart CartRepository MailBuider Module
    18. 18. Gestion du changement 21 Dégradation lors des évolutions Réévaluer les axes de changements à chaque évolution
    19. 19. Quelques concepts 22 Couplage: Rigidité: faire évoluer l’un sanschaine de dépendances modifier lautre Fragilité : en touchant un module, on casse un comportement dans un autre modèle apparemment indépendant

    ×