Upload
nicolas-capponi
View
941
Download
1
Embed Size (px)
DESCRIPTION
Présentation Agile Grenoble 2012 - Nicolas Capponi & Guillaume Gardais
Citation preview
1
Well-crafted softwareun code maintenable avec le principe de responsabilité
unique
Guillaume Gardais, Nicolas Capponi - Agile Grenoble 2012
2Contrat de session
SOLID / GRASPDes solutions magiques
Principe de Responsabilité Unique
3Qui sommes nous ?
@Wace99
@ncapponi
Kelkoo depuis 2010
DéveloppeurArchitecte logiciel
Kelkoo depuis 2003
DéveloppeurArchitecte logiciel
4Institut Médico Légal du Code
avecNicolas dans le rôle du Docteur Robert « Uncle Bob »
MartinGuillaume dans le rôle de l’Etudiant Codeur
Application
5Indices
2 Décrire la classe en une phrase: sans OU, sans ET
Beaucoup de variables d'instances, de méthodes, de lignes de codes, de classes1
3 Nom de classe générique: Manager, Process, Service, Helper, Tools
4 Code dupliqué: responsabilité diluée entre plusieurs éléments
7Indices (suite)
5 Métrique : LCOM4
Métrique : complexité cyclomatique6
7 Métrique : package cohésion
9Radiographie du cadavre
10Solution: Diviser
1 1 classe pour 1 responsabilité
11Solution: Facade
2 Simplifier l’utilisation de « Cart »
12Solution: Interface
3 Séparer les responsabilités
13Solution: Visiteur
4 Respecter l’encapsulation
14Quelle solution choisir ?
15Un peu de théorie
Principe de responsabilité unique (SRP)
Une classe ne doit avoir qu’une seule raison de
changer
Chaque responsabilité est un axe de changement
Robert Martin 1995/2002
16Conclusion
SRP est un principe, pas une règle
Contexte
17
Code, références:https://github.com/ncapponi/srp-2012
Merci
@Wace99@ncapponi
18
20Identifier les responsabilités
Rôle
Familles de fonctions
ModuleCart CartRepository MailBuider
Architecte
Stockageen BDD Sérialise
Product Marketing
AjouterUn produit
EnleverUn produit
Contenu duMail à envoyer
21Gestion du changement
Dégradation lors des évolutions
Réévaluer les axes de changements
à chaque évolution
22Quelques concepts
Couplage: faire évoluer l’un sans
modifier l'autre
Rigidité: chaine de dépendances
Fragilité : en touchant un module, on casse un comportement dans un autre
modèle apparemment indépendant