De nos jours, je ne trouve pas utile de débattre de ce qui constitue ou non une responsabilité ou une raison de changer. Je proposerais un principe de peine minimum à la place:
Principe de deuil minimum: le code doit chercher à minimiser la probabilité d’exiger des modifications ou à en simplifier la modification.
Comment ça Ne devrait pas demander à un spécialiste en sciences de la fusée de comprendre pourquoi cela peut aider à réduire les coûts de maintenance. Espérons que cela ne devrait pas être un point de débat sans fin, mais comme dans le cas de SOLID en général, il n’est pas possible de l’appliquer aveuglément partout. C'est quelque chose à considérer tout en équilibrant les compromis.
Quant à la probabilité d’exiger des changements, cela diminue avec:
- Bon test (fiabilité améliorée).
- N'impliquant que le strict minimum nécessaire pour effectuer quelque chose de spécifique (cela peut inclure la réduction des couplages afférents).
- Rendre le code badass à ce qu'il fait (voir Principe Make Badass).
Quant à la difficulté de faire des changements, elle monte avec des couplages efférents. Les tests introduisent des couplages efférents mais améliorent la fiabilité. Bien fait, il fait généralement plus de bien que de mal et est tout à fait acceptable et promu par le principe du minimum de chagrin.
Assurez le principe de Badass: les classes utilisées dans de nombreux endroits devraient être géniales. Ils doivent être fiables, efficaces si cela est lié à leur qualité, etc.
Et le principe Make Badass est lié au principe Minimum Grief, car les choses badass trouveront une probabilité moins grande d’exiger des changements que les choses qui ne valent que ce qu’elles font.
J'aurais commencé par souligner le paradoxe mentionné ci-dessus, puis indiquer que le PRS dépend fortement du niveau de granularité que vous souhaitez prendre en compte et que, si vous le prenez suffisamment loin, toute classe contenant plus d'une propriété ou une seule méthode viole il.
Du point de vue du SRP, une classe qui fait à peine quoi que ce soit n'aurait certainement qu'une seule raison (parfois zéro) de changer:
class Float
{
public:
explicit Float(float val);
float get() const;
void set(float new_val);
};
Cela n'a pratiquement aucune raison de changer! C'est mieux que SRP. C'est ZRP!
Sauf que je dirais que c'est une violation flagrante du principe Make Badass. C'est aussi absolument nul. Quelque chose qui fait si peu ne peut pas espérer être dur à cuire. Il contient trop peu d'informations (TLI). Et naturellement, lorsque vous avez quelque chose qui est TLI, il ne peut rien faire de vraiment significatif, pas même avec les informations qu’il encapsule, il doit donc le divulguer au monde extérieur dans l’espoir que quelqu'un d'autre fasse réellement quelque chose de significatif et de dur à cuire. Et cette fuite est acceptable pour quelque chose qui est juste destiné à agréger des données et rien de plus, mais ce seuil est la différence que je vois entre "données" et "objets".
Bien sûr, quelque chose qui est TMI est mauvais aussi. Nous pourrions mettre tout notre logiciel dans une classe. Il peut même n’avoir qu’une runméthode. Et quelqu'un pourrait même dire qu'il a maintenant une très grande raison de changer: "Cette classe ne devra être changée que si le logiciel doit être amélioré." Je suis stupide, mais bien sûr, nous pouvons imaginer tous les problèmes de maintenance liés à cela.
Il y a donc un équilibre à trouver dans la granularité ou la grossièreté des objets que vous concevez. Je le juge souvent par la quantité d’informations que vous devez divulguer au monde extérieur et par la quantité de fonctionnalités significatives qu’elle peut exécuter. Je trouve souvent que le principe Make Badass est utile pour trouver l’équilibre tout en le combinant avec le principe Minimum deuil.