Reconnaître une violation du principe de responsabilité unique

Dans un article précédent, j’ai parlé de programmation événementielle et comment il était possible d’utiliser les événements Symfony afin d’écrire du code qui respecte le principe de responsabilité unique. L’exemple était extrêmement simple et il est souvent plus difficile d’identifier les différentes responsabilités d’une classe lorsque celle-ci fait plusieurs centaines de lignes.

Le nombre de lignes de code présent (et le nombre de variables d’instances présentes) dans une classe peut être un signal d’alarme. Un autre indicateur est la présence de méthodes privées qui ont pour but de déléguer des tâches précises. Bien souvent ces méthodes peuvent être extraites dans une ou plusieurs classes indépendantes.

Si vous souhaitez approfondir les principes d’un code SOLID et comment écrire des classes qui soient facilement extensibles, réutilisables et maintenables, je ne peux que vous conseiller l’excellent livre de Matthias NOBACK : Principles of Package Design. Certainement l’une des meilleures ressources sur le sujet et que tout développeur devrait avoir lu.