G. Saint Etienne & Thierry Cros très fortement inspiré par Uncle Bob

*

*

*Disposition, ordonnance d'un édifice.

Architecture Foundation London, by Zaha Hadid

*

*

*Uncle Bob says

*

*

*

dependencies between software

packages in the Gentoo Linux operating

system. In total there are 14319 packages

with 63988 dependencies between them!

*

*

*

*A quick view

*

*Quelques rappels

*Êtes vous S.O.L.I.D. ?

*

*Object Encapsulation

*Inheritance

*Polymorphism

*Single Responsability Principle

*

*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)

*

*Du spaghetti …

*… Au multiples couches

*

*

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

*

*Ensemble dans le même package si (ré)utilisés

en même temps

*

*Si 2 classes changent ensemble alors elles

devraient se retrouver ensemble dans le même

package.

*Similaire à Open Close Principle

*Gain en maintenabilité.

*

*

*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

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

*

*Let’s code for real

*

*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

*

*Independant of Frameworks

*Fully and Unit Testable… and very fast!

*Independant of UI

*Independant of Database

*Independant of any External Agency

*

*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

*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)

* Always remember

*

* http://blog.8thlight.com/uncle-bob/2012/08/13/the-clean-architecture.html

* http://blog.kamil.dworakowski.name/2010/08/from-layers-to-hexagon-

architecture.html

* http://agilitateur.azeau.com/post/2012/03/05/Conception-logicielle

* http://www.objectmentor.com/resources/articles/granularity.pdf

* http://java.boot.by/scea5-guide/ch01.html

* Dojos

* https://github.com/martinsson/DevelopersAnonymous/blob/master/c%23/Guild

edRose/GildedRose.cs