Devops for Growth

“A: Les modules de plus haut niveau ne doivent pas dépendre des modules de plus bas niveau. Les deux doivent dépendre des abstractions”

“B: Les abstractions ne doivent pas dépendre des détails. Les détails doivent dépendre des abstractions”

Le terme d’inversion de dépendance (DIP) est souvent assimilé aux termes d’Injection de dépendance et Inversion of Control (IoC). Pour ma part j’estime que l’injection de dépendance est un sujet très important de connaître et franchement, pour construire des applications robustes et évolutives il est très difficile de passer à côté. Je vais vous épargner le grand débat théorique dont j’ai l’habitude :) et cette fois ci passons directement à l’exemple. Le but de DI (et autre principes S.O.L.I.D) est de palier les problèmes liés au mauvais design des applications. Bien que vous utilisez l’approche OOP, votre code est structuré à l’intérieur des classes mais il est toujours très difficile à le modifier et à le faire évoluer. C’est à cause de ces dépendances que les classes ont entre elles et si vous modifiez une classe il y a un risque qu’une autre “pète” à l’autre bout de la planète :)

Some authors allege that design patterns don't differ significantly from other forms of abstraction, and that the use of new terminology (borrowed from the architecture community) to describe existing phenomena in the field of programming is unnecessary. The Model-View-Controller paradigm is touted as an example of a "pattern" which predates the concept of "design patterns" by several years. It is further argued by some that the primary contribution of the Design Patterns community (and the Gang of Four book) was the use of Alexander's pattern language as a form of documentation; a practice which is often ignored in the literature.

“Une classe ne doit avoir qu'une raison pour qu'elle change”

Qu’est-ce que cela veut dire ?  Chaque développeur dans son travail de tous les jours a des problèmes plus ou moins complexes à résoudre. Il est souvent très difficile de résoudre un problème en le traitant dans sa globalité, surtout quand les paramètres qui le définissent changent de temps en temps. En découpant le “gros” problème en des mini-problèmes permet de les résoudre beaucoup plus facilement. En fait, chaque mini-problème peut être assimilé à une tâche concrète qui à son tour peut être implémentée à l’aide d’une simple classe. Puisque chaque classe a une simple tâche à accomplir il y a par conséquence une seule raison pour qu’elle change. Nous pouvons donc changer juste cette classe si la tâche correspondante change. Comme vous-vous en doutez une tâche = une responsabilité.

Cela signifie également que nous devons apprendre à découper les problèmes car les problèmes complexes sont difficile à résoudre en tant que l’ensemble indivisible. Cela permet de réduire la complexité de l’ensemble car chaque mini-problème peut être traité séparément.

L’application de SRP est aussi bénéfique à la qualité de votre code ainsi qu’à la modélisation objet que vous faites. Pourquoi ? Car le code est:

• plus robuste.
• plus facile à lire et à comprendre.
• plus facile à tester et à maintenir.
• plus facile à étendre avec de nouvelles fonctionnalités.