J'adresse cette question à des personnes ayant des connaissances avancées dans le domaine de l'architecture logicielle. J'essaie de comprendre l'idée de principe de responsabilité unique (SOLID) liée à l'idée d'élimination de la redondance de code. Ma perception de la duplication de code était que la duplication de code est quelque chose de mal qui doit être corrigé et éliminé. En fait, je lis «Clean Architecture» (Robert C. Martin) et ma perception a changé et je suis un peu confus.
Le SRP met l’accent sur l’acteur, alors Robert Martin écrit: «Un module devrait être responsable devant un et un seul acteur». À titre d'exemple, R. Martin parle de deux classes (modules). La première classe contient la méthode «sharedPay ()» spécifiée par le service comptable. L'autre classe contient la méthode «reportHours ()» spécifiée par un autre acteur, le service des ressources humaines. Les deux fonctions partagent un algorithme commun (par exemple quelque chose comme le calcul de l'heure). L'approche naturelle serait de déplacer l'algorithme commun vers une autre classe et d'éliminer la duplication de code. Après cela, les deux fonctions appelleraient l'algorithme dans la nouvelle classe. Imaginez que le service comptable doit changer l'algorithme (dans la nouvelle classe). Après le changement, le service des ressources humaines utilise un nouvel algorithme (invalide). Il y a un problème et le problème est causé par la rupture du SRP. La classe d'algorithme (module) est responsable devant deux acteurs. D'un autre côté, nous aurions une duplication de code inutile, ce qui me rend agité.
Peut-être que mon approche dogmatique de la duplication de code est erronée, et il n'y a rien de mal à avoir le même code à de nombreux endroits. N'est-ce pas? Si je regarde les choses d'un point de vue différent, alors je vois qu'il existe plusieurs algorithmes / ou juste des parties de code utilisées par plusieurs clients (acteurs). Et parfois, le code utilisé doit être modifié. C'est quelque chose de naturel pour moi. Quelle serait une autre façon? C’est pourquoi je ne comprends pas très bien pourquoi ne pas placer la duplication dans une autre classe. Un autre exemple avec une vue différente, deux classes avec une fonction chacune, partageant un algorithme commun mais toutes deux spécifiées par le service comptable. Il n'y a pas de coupure SRP, car il n'y a qu'un seul acteur par le même problème, car un changement peut invalider l'autre classe. C'est en quelque sorte très inexact ...
Peut-être que je ne comprends pas le SRP et l'idée derrière ...
4 Réponses :
Comme vous le lirez plus tard dans le livre:
Les architectes tombent souvent dans un piège - un piège qui repose sur leur peur de la duplication. La duplication est généralement une mauvaise chose dans les logiciels. Nous n'aimons pas le code dupliqué. Lorsque le code est vraiment dupliqué, nous sommes tenus par l'honneur en tant que professionnels de le réduire et de l'éliminer. Mais il existe différents types de duplication.
Il existe une vraie duplication , dans laquelle chaque modification d'une instance nécessite la même modification pour chaque copie de cette instance. Ensuite, il y a duplication fausse ou accidentelle . Si deux sections de code apparemment dupliquées évoluent selon des chemins différents - si elles changent à des rythmes différents et pour des raisons différentes - alors ce ne sont pas des vrais doublons .
Je pense qu'il explique très bien votre doute.
Avec l'expérience et une attention continue, vous comprendrez comment utiliser SRP principale avec la duplication de code.
Mon opinion personnelle est qu'au fur et à mesure que vous approfondirez vos recherches dans les modèles de conception et l'architecture, vous serez confronté à des questions philosophiques auxquelles les utilisateurs de stackoverflow ne peuvent pas (à 100%) répondre;)
SRP est juste un terme marketing, qui a tenté de promouvoir les concepts beaucoup plus anciens (et bien mieux définis) de cohésion et de couplage . Je suggérerais de simplement revenir à ces termes chaque fois qu'il y a une question sur SRP.
Celles-ci ne disent rien sur la duplication de code en tant que telle, mais elles impliquent que les "données" devraient toujours être accompagnées de tous les comportements associés.
Cela signifie qu'il ne peut pas vraiment y avoir de "code dupliqué" faisant la même chose, car il n'aurait pas accès aux mêmes données que l'original (puisque les données sont toujours encapsulées).
Cependant, il peut y avoir du code dupliqué qui fait essentiellement la même chose, mais pour un concept différent, avec ses propres données, mais peut-être similaires. Ces choses changeraient également pour différentes raisons, donc cela correspondrait à ce que dit Oncle Bob, je suppose.
Je voudrais ajouter: aucune décision de conception ne doit être statique.
À un moment donné, il peut être judicieux d'extraire le code dupliqué et de le partager à partir d'un seul endroit. À mesure que les exigences changent, il peut être nécessaire de repenser cette décision et de "dupliquer" à nouveau le code avant de le modifier spécifiquement pour un utilisateur.
J'ai été confronté aux mêmes questions il y a quelques semestres. L'importance et le concept de base de la compréhension de SRP est également de comprendre le code redondant.
Vous devez d'abord vous familiariser avec le concept de code redondant. Prenons un exemple TRÈS simple:
Actor1 utilise la classe A:
Qui a la responsabilité de calculer des entrées spécifiques données à partir de Actor1 et Actor1 UNIQUEMENT, puis de renvoyer le résultat.
Actor2 utilisera la classe B:
Qui a la responsabilité de calculer quelque chose de différent en fonction des entrées spécifiques de Actor2 et ensuite de retourner le résultat. Cependant, lors de la conception de la classe, nous réalisons qu'une partie du calcul contient le même code que la classe A.
Voici un exemple où la classe B contiendra du code redondant si nous procédons à notre conception, car elle contiendra du code dupliqué, qui existe déjà dans la classe A.
La solution:
Selon SOLID (principe ouvert / fermé), nous ne sommes PAS autorisés à revenir en arrière et à changer de classe A et à permettre à la classe B de l'utiliser. La raison est que nous ne sommes pas autorisés à supprimer / modifier tout code existant dans la classe A. La raison en est que nous pourrions casser le code d'Actor1 ou d'un autre acteur inconnu.
À la place, nous écrivons une classe C qui étend la classe A, donc le calcul spécifique peut être utilisé via la classe C, et peut donc être utilisé à la fois par la classe B et par tout autre cals à l'avenir.
J'espère que cela répond à votre question!
Copie possible de Je n'arrive pas à comprendre les principes et les modèles de conception SOLID