Skip to content

junior344/Learn_Clean_Architescture

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

3 Commits
 
 

Repository files navigation

Learn_Clean_Architescture

les principes S.O.L.I.D

- Principes imaginés par Robert C. Martin 
- Objectif: creer du code facilement modifiable, robuste et simple a comprendre
- Initialement concu pour les classes
- Utilisable a l'echelle des modules voir des services

5 principes

- Single responsibility principle
    - une classe ne doit avoir qu'une seule raison de changer
    - Mieux : une classe ne doit etre responsable que d'un seul acteur
    - le principe parle de roles et acteurs, c'est a dire d'utilisateur du systeme
    - le code doit etre a l'image des utilisateurs et non des developpeurs

- Open / Closed principle
    - une classe doit etre ouverte a l'extension mais fermée a la modification
    - Penser en termes de contrats
    - Modifier une classe a des repercussions sur ceux qui en dépendent
    - Dependre en direction de la stabilité

- Liskov Substitution Principale
    - Une classe qui implemente un contrat doit-etre parfaitement substituable par un autre classe qui implemente le meme contrat
    - Toutes les implementations d'une interface doivent partager la meme signature de methode mais egalement la meme sematique
    - De plus, l'interface ne doit pas s'adapter a la classe concrete mais l'inverse (Implementation Leakage)

- Interface Segregation Principle
    - Une classe ne devrait pas dependre des elements d'une classe qu'elle n'utilise pas
    - En d'autre termes: une classe specifique a un consommateur vaut mieux qu'une classe generique
    - Qu'il s'agisse d'un client ou d'une sous-classe, on ne devrait pas etre impacté par de changement qui ne nous concernent pas

- Dependency Inversion Principale 
    - Les High Level Modules ne doivent pas dependre des Low Level Modules, Mais les deux devraient dependre d'une interface commune.
    - Les abstractions ne doivent pas dependre des details (implementation) mais l'inverse.
    - Maintenir la separation entre differents niveau au sein d'un moduler
    - L'infrastructure depend du domaine et non l'inverse
    - Mais les deux dependent d'une interface commune qui vit dans le meme module que la classe qui l'utilise

About

No description, website, or topics provided.

Resources

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published