Afin d’éviter une certaine complexité du code, des classes à plusieurs milliers de lignes et une forte dépendance, une classe / une méthode ne doit avoir qu’une seule responsabilité, un seul rôle. Elle ne doit donc avoir qu’une seule raison d’être modifiée, et ne pas nécessiter d’être impactée si une fonctionnalité autre doit évoluer.

Un code découpé sera moins complexe donc plus facile à lire et à comprendre, plus maintenable et évolutif, plus facilement testable.

Ouvert / fermé

Une entité de l’application (une classe, une méthode, autre) doit être fermée à toute modification directe mais doit être ouverte à l’extension. Une classe par exemple, peut être étendue afin de modifier son comportement. Elle est ouverte à l’extension, mais fermée à la modification directe.

On utilise souvent des classes abstraites ou des interfaces pour imposer les rouages du fonctionnement d’un objet, mais c’est ensuite à chaque classe d’implémentation de cet objet de décrire le comportement de chaque méthode.

Substitution de Liskov

Ce principe dit que :

Si S est un sous-type de T, alors tout objet de type T peut être remplacé par un objet de type S sans altérer les propriétés désirables du programme concerné.
Pour une méthode par exemple, cela implique que si elle est étendue dans une classe elle devra y avoir par rapport à la classe mère le même type de retour, les mêmes types pour ses arguments, générer les mêmes types d’erreurs / exceptions.

Séparation des interfaces

Le principe est qu’une classe ne devrait pas dépendre d’éléments ou des méthodes qu’il n’utilise pas. En ceci, les interfaces permettent d’imposer à une classe d’avoir des éléments découpés, sans forcément qu’il doive avoir tout un ensemble d’éléments. Ceci découpe mieux, apporte un couplage faible, plus simple à maintenir.

Inversion des dépendances

Le principe est qu’un objet haut niveau ne doit pas dépendre d’un objet bas niveau, mais que les deux doivent dépendre d’abstractions.

Les objets de haut niveau étant vos objets métiers (un client, un contrat, une facture, etc.) et les objets bas niveau étant les objets plus techniques (communication application <=> base de données, gestion des logs, gestion de la session, etc.), ce principe dit que tout changement bas niveau ne devra en aucun cas impacter vos objets métiers. Il s’agit là aussi d’amoindrir le couplage fort d’objets.

Conclusion

La mise en application de ces principes n’est en rien une obligation, mais les comprendre et les appliquer sera d’un très grand bénéfice dans vos développements. Avoir des classes et méthodes ayant un rôle unique, respecter le principe d’encapsulation dans des classes fermées mais pouvant être étendues, découper vos interfaces et limiter le couplage fort, tout ces éléments permettront :

Un code mieux découpé.
Un code plus lisible, plus rapidement compréhensible et plus logique.
Un code plus simple à maintenir pour des corrections comme pour des évolutions.
Un code plus facile à documenter, lorsque cela sera nécessaire.
Un code plus facilement testable.

qualité