Le PRS (principe de responsabilité unique) est-il objectif?

Considérez deux concepteurs d'interface utilisateur qui souhaitent concevoir des conceptions «attrayantes pour l'utilisateur». "L'attraction des utilisateurs" est un concept qui n'est pas objectif et ne réside que dans l'esprit des designers. Ainsi, le designer A pourrait par exemple choisir la couleur rouge, tandis que le designer B choisit le bleu. Le concepteur A crée une mise en page entièrement différente du concepteur B, etc.

J'ai lu sur SRP (Single Responsibility Principle) et ce que j'ai compris était une sorte d'analyse subjective ou une répartition des responsabilités qui peuvent varier d'un concepteur OO à un autre concepteur OO. Ai-je raison? En d'autres termes, est-il possible d'avoir deux excellents analyseurs et concepteurs orientés objet qui proposent deux conceptions différentes pour un système basé sur le principe SRP?

Une bonne question et une sur laquelle je réfléchissais souvent.

Je dirais pas objectif, non. Certainement subjectif. La façon dont vous abordez la résolution des problèmes dépend de votre philosophie envers ce type de problème. La science nous montre qu'il peut exister de nombreuses façons différentes de résoudre efficacement le même problème. La science nous montre également que les peuples des continents peuvent proposer les mêmes solutions indépendamment, et donc certaines solutions sont plus évidentes que d'autres. Dans tous les cas, juger les solutions en termes de «meilleures» dépend de vos critères.

Vraiment, ce que l'on pourrait voir comme deux parties du même tout, un autre pourrait voir comme deux concepts totalement distincts. On le voit tout le temps quand on regarde comment les mainteneurs de différentes bibliothèques de code abordent le même problème. Et pourtant, les deux solutions fonctionnent très bien.

(PS. Modifié cette réponse car la dernière question du PO demande le contraire du titre de la question.)

Le principe lui-même est objectif, mais il existe tellement de façons différentes de mettre en œuvre quelque chose qui suit le principe, que deux développeurs indépendants proposeront presque toujours des conceptions de système assez différentes pour la même application.

Il est même probable que le même développeur, faisant deux fois la même conception, propose toujours deux solutions qui diffèrent au moins partiellement.

Pour qu'un principe fasse en sorte que les conceptions du système soient toujours identiques, il devrait couvrir tous les aspects des décisions de conception. Le principe de responsabilité unique ne couvre qu'une petite partie des décisions de conception impliquées dans la conception de tout système.

L'application du principe est subjective. Cependant, «subjectif» n'équivaut pas à «préférence» de la même façon que l'esthétique.

Il y a des extrêmes évidents. Une classe avec exactement une méthode, avec seulement quelques lignes de code, qui n'appelle pas d'autres classes, suit définitivement le SRP. D'un autre côté, une classe avec deux méthodes, l'une qui contient une implémentation complète du courrier électronique via des sockets bruts et une autre qui crée un formulaire GUI, ne suit certainement pas le SRP.

L'esthétique est une mauvaise analogie. Une meilleure analogie serait les concepts informatiques bien connus de couplage et de cohésion . Aucun de ces attributs n'est en noir et blanc, vrai ou faux. Cependant, ils sont mesurables, même s'il y a un élément qualitatif. Si vous montrez à un groupe de développeurs expérimentés deux conceptions distinctes pour la même fonctionnalité, ils vont donner des lectures similaires sur lesquelles la conception a plus de couplage et / ou de cohésion.

En fait, le SRP n'est essentiellement qu'une cohésion fonctionnelle. Il indique que les parties de certains modules (par exemple la classe) doivent être regroupées car elles contribuent toutes à la même fonction, et pour aucune autre raison. La "fonction" peut être sujette à interprétation - certaines personnes peuvent l'interpréter littéralement comme une seule déclaration de fonction (ou méthode ou procédure) , d'autres peuvent prendre un peu de recul et penser à une fonction comme "envoyer un e-mail" ou "jouer de la musique" , mais la marge de manœuvre est encore limitée. "Gérer les choses" n'est pas une description fonctionnelle valide.

Il existe une définition objective de la «responsabilité» comme une «raison de changer». Au moment de la programmation, toutes les raisons de changer se situent dans le futur, donc le programmeur ne peut que deviner en fonction de son expérience et de ses connaissances du domaine. L'analyse des responsabilités est donc une sorte de prévision, en partie subjective.

Le SRP est objectif; les implémentations sont subjectives

deux implémentations avec exactement la même fonctionnalité peuvent utiliser des structures internes complètement différentes, ce qui entraîne des classes et des méthodes différentes, et les deux peuvent satisfaire SRP

s'ils utilisent les mêmes méthodes et le même état, et que les deux sont normalisés (minimal / non redondant), ils se retrouveront - en théorie - avec les mêmes classes et méthodes sous SRP.

mais je ne peux pas le prouver. Encore.