Le principe de responsabilité unique est-il une règle de la POO ?[fermé]

Question

Un répondre à une question Stack Overflow indiquait qu'un framework particulier violait une règle POO claire et simple :Principe de responsabilité unique (SRP).

Le principe de responsabilité unique est-il vraiment une règle de POO ?

Ma compréhension de la définition de la programmation orientée objet est « un paradigme où les objets et leur comportement sont utilisés pour créer des logiciels ».Cela inclut les techniques suivantes :Encapsulation, polymorphisme et héritage.

Maintenant, ne vous méprenez pas - je pense que SRP est la clé de la plupart des bonnes conceptions OO, mais je pense qu'il y a des cas où ce principe peut et doit être enfreint (tout comme les règles de normalisation des bases de données).Je fais valoir de manière agressive les avantages de SRP, et la grande majorité de mon code suit ce principe.

Mais est-ce une règle, et implique donc qu’elle ne doit pas être enfreinte ?

Answer 1

Très peu de règles, voire aucune, en matière de développement logiciel sont sans exception.Certaines personnes pensent qu'il n'y a pas de place pour aller à mais ils ont tort.

En ce qui concerne la POO, il n'existe pas de définition unique de l'orientation objet. Ainsi, selon la personne à qui vous demandez, vous obtiendrez un ensemble différent de principes, de modèles et de pratiques stricts et souples.

L'idée classique de la POO est que les messages sont envoyés à des objets autrement opaques et que les objets interprètent le message en connaissance de leurs propres entrailles et remplissent ensuite une fonction quelconque.

SRP est un principe de génie logiciel qui peut s'appliquer au rôle d'une classe, d'une fonction ou d'un module.Il contribue à la cohésion de quelque chose afin qu'il se comporte bien sans que des éléments sans rapport n'y pendent ou n'aient de multiples rôles qui s'entrelacent et compliquent les choses.

Même avec une seule responsabilité, cela peut aller d’une seule fonction à un groupe de fonctions vaguement liées qui font partie d’un thème commun.Tant que vous évitez de truquer un élément pour qu'il assume la responsabilité de quelque chose pour lequel il n'a pas été initialement conçu ou de faire une autre chose ad hoc qui dilue la simplicité d'un objet, alors violez le principe que vous souhaitez.

Mais je trouve qu'il est plus facile d'obtenir un SRP correct que de faire quelque chose de plus élaboré et tout aussi robuste.

Answer 2

Aucune de ces règles n’est une loi.Il s’agit davantage de lignes directrices et de meilleures pratiques.Il y a des moments où cela n’a pas de sens de suivre « les règles » et où vous devez faire ce qui est le mieux adapté à votre situation.

N'ayez pas peur de faire ce que vous pensez être juste.Vous pourriez en fait proposer des règles plus récentes et meilleures.

Answer 3

Pour citer le capitaine Barbossa :

"..Et deuxièmement, vous devez être un pirate pour que le code du pirate s'applique et vous ne l'êtes pas.Et troisièmement, le code est plus ce que vous appelleriez des « lignes directrices » que de véritables règles...."

Pour citer Jack Sparrow et Gibbs."Je pensais que tu étais censé rester au code." M.Gibbs :"Nous pensions qu'il s'agissait de lignes directrices plus concrètes."

Il est donc clair que les Pirates le comprennent assez bien.

Les "règles" pourraient être comprises via les schémas de mouvement comme des "Forces".

Il existe donc une force qui tente de faire en sorte que la classe ait une seule responsabilité.(cohésion)

Mais il existe également une force qui tente de limiter le couplage avec d’autres classes.

Comme pour toute conception (pas seulement le code), la réponse est que cela dépend.

Answer 4

Ahh, je suppose que cela concerne une réponse que j'ai donnée.:)

Comme pour la plupart des règles et lois, il existe des motifs sous-jacents pour lesquels ces règles sont pertinentes : si le motif sous-jacent n'est pas présent ou applicable à votre cas, vous êtes alors libre de contourner/enfreindre les règles en fonction de vos propres besoins.

Cela étant dit, SRP n'est pas une règle de POO en soi, mais est considéré comme une bonne pratique pour créer des applications POO qui sont à la fois facilement extensibles et testables unitairement.

Ce sont deux caractéristiques que je considère comme de la plus haute importance dans le développement d’applications d’entreprise, où la maintenance des applications existantes prend plus de temps que le développement de nouvelles applications.

Answer 5

Comme l’ont dit de nombreuses autres affiches, toutes les règles sont faites pour être enfreintes.
Cela étant dit, je pense que SRP est l'une des règles les plus importantes pour écrire du bon code.Ce n'est pas spécifique à la programmation orientée objet, mais la partie "encapsulation" de la POO est très difficile à réaliser correctement si la classe n'a pas une seule responsabilité.

Après tout, comment encapsuler correctement et simplement une classe avec de multiples responsabilités ?Habituellement, la réponse est plusieurs interfaces et dans de nombreuses langues, ce qui peut aider beaucoup, mais les utilisateurs de votre classe sont toujours déroutés par le fait que cela peut s'appliquer de manières complètement différentes dans différentes situations.

Answer 6

SRP n'est qu'une autre expression de FAI :-) .

Et le "P" signifie "principe", pas "règle" :D