Un code maintenable avec le principe de responsabilite unique

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