Cette série est un récit gratuit et très court du livre Clean Architecture de Robert Martin (Uncle Bob) en 2018. La partie précédente est ici .
Principes de conception
Les principes SOLID nous indiquent comment nous pouvons combiner nos fonctions et données en classes, et comment ces classes doivent être interconnectées. Autrement dit, ces principes se situent au niveau intermédiaire. Cependant, ils s'appliquent également au niveau des composants (architecture de haut niveau).
Les principes SOLID ont commencé à la fin des années 1980 et se sont stabilisés au début des années 2000.
SRP: principe de responsabilité unique
Historiquement, ce principe a été formulé comme suit: un module doit avoir une et une seule raison de changer.
Cependant, l'oncle Bob suggère une formulation différente, plus précise: le module devrait être responsable d'un et d'un seul acteur .
Un module est un ensemble connexe de fonctions et de structures de données.
Un exemple d'une violation du principe: la classe Employee
avec trois méthodes calculatePay()
, reportHours()
, save()
. Ces trois méthodes s'appliquent à différents acteurs. calculatePay()
- c'est la comptabilité, reportHours()
- c'est le service du personnel, save()
- c'est l'administrateur de la base de données. Si l'un des acteurs demande à modifier sa méthode, cela peut casser la logique des autres méthodes. Cela rend également difficile la fusion des changements des différents acteurs.
– . , .
OCP: /
, .
: .
.
: -. - . OCP , , , . , , , . , .. .
, , .
OCP , .
LSP:
: S T, T S - .
, , .
LSP: /.
LSP: , REST- . . , , .
ISP:
, .
, , .
, . ISP , , , . , , . .
DIP:
, .
Java , .
, , , java.lang.String
. . , , . .
. , , .
.
, ? :
À l'avenir, nous nous référerons plus souvent au principe DIP qu'à d'autres principes, car il nous dicte la règle la plus importante pour construire une architecture compétente: les règles de dépendance .
À suivre...