• Like
Un code maintenable avec le principe de responsabilite unique
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

Un code maintenable avec le principe de responsabilite unique

  • 867 views
Published

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

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

Published in Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
867
On SlideShare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
19
Comments
0
Likes
1

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    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.

Transcript

  • 1. Well-crafted softwareun 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 avecNicolas 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 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. Indices (suite) 7 5 Métrique : LCOM4 6 Métrique : complexité cyclomatique 7 Métrique : package cohésion
  • 7. Radiographie du cadavre 9
  • 8. Solution: Diviser 101 1 classe pour 1 responsabilité
  • 9. Solution: Facade 112 Simplifier l’utilisation de « Cart »
  • 10. Solution: Interface 123 Séparer les responsabilités
  • 11. Solution: Visiteur 134 Respecter l’encapsulation
  • 12. Quelle solution choisir ? 14
  • 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. Conclusion 16 Contexte SRP est un principe, pas une règle
  • 15. Merci 17 Code, références: https://github.com/ncapponi/srp-2012 @Wace99 @ncapponi
  • 16. 18
  • 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. Gestion du changement 21 Dégradation lors des évolutions Réévaluer les axes de changements à chaque évolution
  • 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