25. *
*Open Close Principle
*Ouvert aux extensions / Fermé aux modifications
*Interface Segregation Principle
*Un composant ne doit jamais être forcé de dépendre d’une interface (ou un
package) qu’il n’utilise pas
*Dependency Inversion Principle
*Les éléments de « haut » niveau ne doivent pas dépendre des
éléments de « bas » niveaux
*Les abstractions ne doivent pas dépendre des détails (implémentations)
29. *
*La granularité de la réutilisation est la
granularité de ce que est livré/livrable.
*Ne ré-utilisez rien qui ne soit livrable
indépendamment.
*Ré-utilisez si vous pouvez vous sentir comme
un simple consommateur d’un livrable.
31. *
*Si 2 classes changent ensemble alors elles
devraient se retrouver ensemble dans le même
package.
*Similaire à Open Close Principle
*Gain en maintenabilité.
33. *
*Stable Dependencies Principle (SDP)
*Moins un package est stable, moins il devrait y avoir de
dépendances vers lui (moins de couplage).
*Stable Abstractions Principle (SAP)
*Les packages ne contenant que des abstractions doivent être
les plus stables possibles.
*Forte Cohérence Interne / Faible Couplage Externe
34. Concepts
d'architecture
Concepts
d'implémentation
Détails
d'implémentation
Dépendances
Ne dépendent que
d'autres concepts
d'architecture
Peuvent dépendre
de concepts
d'architecture ou de
d'autres concepts
d'implémentation
Dépendent de
concepts
d'architecture et de
concepts
d'implémentation
Niveau
d'abstraction
Entièrement
abstraits
Mélange
d'abstraction et de
détails
Entièrement
composés de détails
Niveau de stabilité Stabilité maximale Partiellement stable
Change au moindre
changement dans le
logiciel
36. *
*A good architecture allows major decisions to be defered
*What and how to instanciate
*How display it
*How store it ….
*A good architecture maximes the number of decision not
made
37. *
*Independant of Frameworks
*Fully and Unit Testable… and very fast!
*Independant of UI
*Independant of Database
*Independant of any External Agency
38.
39. *
*A l’extérieur: l’infrastructure, les services externes
*la persistence, l’UI en font partie
*A l’intérieur: la description des comportements et
des entités
*Dépendances: de l’extérieur vers l’intérieur
seulement
40. *Les entités
*On en parle demain dans « TDD vs DBO »
*Uses cases
*Ce sont des « Application business rules »
*Jamais impacté par les changements externes (UI, DB, etc…)
*Interface Adapters
*Convertissent les entités vers des formats
adaptés aux infrastructures
*Frameworks & Drivers
*Fournissent des services (persistence,
présentation, quincaillerie en tous genre)