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
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
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
Notas del editor
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.