Classes

Le principe même de l’orienté objet et des classes permet d’accroître l’organisation du code et donc de s’instruire dans une démarche de clean code. Aussi la programmation orientée objet sera un atout incontestable mais peut vite se transformer en cauchemar si elle est mal employée.

Commençons donc par respecter l'ordonnancement des informations au sein d’une classe. Les déclarations d’attributs doivent figurer en premiers lieux, viennent d’abord les attributs publics, puis les attributs protégés, puis enfin les attributs privés. S’en suivent les déclarations des constantes dans le même ordre (public, puis protégés, puis privés). Le constructeur - si nécessaire - fait alors son apparition. Enfin le reste de la classe devra suivre le sens de lecture du code contenu. Les méthodes publiques, puis les méthodes protégées et enfin les méthodes privées. Attention, si plusieurs méthodes publiques utilisent une même méthode protégée ou privée, il faudra placer cette dernière juste après l’ensemble des déclarations des méthodes publiques. On parle alors de règle de décroissance, ce qui revient à lire le code comme un livre.

L’encapsulation doit ensuite être utilisée avec parcimonie. En effet, il faut préférer l’utilisation de la visibilité protégée à privée pour simplifier les tests de l’application par la suite. Notez que l’on considère les tests prioritaires. Notez également qu’il est tout à fait possible de trouver des solutions liées à l’encapsulation grâce aux accesseurs et mutateurs par exemple (getters & setters) !

Les classes, tout comme les fonctions, doivent être aussi petites que possible. Prioriser donc le “S” du principe SOLID, et favoriser le principe de responsabilité unique (SPR) au maximum.

Maximisez la cohérence de vos classes. L’évaluation de la cohérence s’effectue souvent en mettant en corrélation les attributs avec les méthodes des classes. Plus il y a d’attributs utilisés au sein d’une méthode, plus la cohésion avec la classe est importante. Lorsque tous les attributs sont utilisés dans toutes les méthodes, on parle alors de cohésion maximale (cas très rare !). La mise en place de cette cohésion implique généralement de réduire le nombre d’attributs présents dans les classes.

Anticipez au mieux les changements : préférez de nombreuses petites classes à une seule grosse classe. Gardez en permanence en tête qu’une évolution portée sur une petite classe aura nettement moins d’impact et entraînera beaucoup moins de vérifications potentielles qu’une grosse classe qui change ! Dans la même idée, il est important de cloisonner le changement autant que possible. Pour ce faire, essayez d’abstraire les concepts pour limiter les mauvais changements par la suite ! (Utilisez donc les interfaces, les classes abstraites, etc…)