Différence entre le principe de responsabilité unique et la séparation des préoccupations

Quelle est la différence entre le principe de responsabilité unique et la séparation des préoccupations?

    Single Responsibility Principle (SRP) – donne à chaque classe une seule raison de changer; et «Raison de changer» == «responsabilité». Exemple: La classe de facturation n’a pas la responsabilité de s’imprimer.

    Séparation des préoccupations (depuis 1974). Préoccupation == caractéristique du système. Prendre soin de chacune des préoccupations: pour chaque préoccupation, d’autres préoccupations ne sont pas pertinentes. Cacher la mise en œuvre du comportement.

    De là

    Séparation des préoccupations et principe de responsabilité unique (SoC vs SRP)

    De l’article lié:

    Séparation des préoccupations (SoC, Separation of Concerns) : processus consistant à diviser un programme informatique en fonctionnalités distinctes qui se chevauchent le moins possible. Une préoccupation est un élément d’intérêt ou de concentration dans un programme. En règle générale, les préoccupations sont synonymes de caractéristiques ou de comportements. http://en.wikipedia.org/wiki/Separation_of_concerns

    Principe de responsabilité unique – chaque object doit avoir une responsabilité unique et tous ses services doivent être étroitement alignés sur cette responsabilité. À un certain niveau, la cohésion est considérée comme synonyme de SRP. http://en.wikipedia.org/wiki/Single_responsibility_principle

    Single Responsibility indique qu’un object est responsable d’une seule unité de travail.

    Seperation of Concerns stipule que les applications doivent être divisées en modules dont les fonctionnalités se chevauchent le moins possible.

    Résultats finaux similaires … applications légèrement différentes.

    À mon avis, le principe de la responsabilité unique est l’un des outils / idiomes permettant de réaliser la séparation des préoccupations.

    Le principe de la responsabilité unique et la séparation des préoccupations sont vraiment la même chose.

    Bien sûr, vous pouvez vous enliser dans une discussion académique en essayant de dégager une sorte de différence entre les deux, mais pourquoi? À toutes fins utiles, ils décrivent la même chose. Le plus gros problème est que les gens sont tellement pris par le désir de savoir exactement ce qu’est une «préoccupation» et une «responsabilité», qu’ils manquent peut-être l’idée derrière SRP et SoC.

    Cette idée consiste simplement à diviser votre base de code en parties isolées faiblement couplées. Cela permet à plusieurs développeurs de travailler sur différentes parties sans s’affecter les uns les autres. Cela permet également à un développeur unique de modifier une pièce isolée sans en casser une autre.

    Ceci est appliqué au niveau du module, par exemple, MVC est un modèle architectural favorisant SRP et SoC. Le code est divisé en modèles, vues et contrôleurs isolés. De cette façon, la modification d’une vue peut être effectuée indépendamment d’un modèle. Deux deux ne sont pas intimement liés.

    À un niveau inférieur, cela devrait être appliqué aux classes également. Au lieu de placer des dizaines de méthodes dans une seule classe, divisez le code en plusieurs. Pour les mêmes raisons.

    Même au niveau de la méthode, séparez les grandes méthodes en méthodes plus petites.

    En principe. SRP est un principe, pas une règle, donc vous n’avez pas à le lire (lire: ne peut / ne devrait pas) le suivre religieusement jusqu’à l’extrême. Cela ne signifie pas aller trop loin et n’avoir qu’une méthode à sept lignes dans chaque classe par exemple. Cela signifie simplement un principe général de séparation du code en parties isolées. Le fait est que cela mènera à une meilleure base de code et à un logiciel plus stable.

    Séparation des préoccupations (SoC). Divisez votre application en fonctions distinctes avec le moins de fonctionnalités possible. (Microsoft).

    “Préoccupation” = “caractéristique distincte” = “section distincte”

    «Concern» fonctionne à la fois aux niveaux haut et bas

    Le principe de la responsabilité unique stipule que chaque module ou classe doit assumer la responsabilité d’une seule partie des fonctionnalités fournies par le logiciel et que cette responsabilité doit être entièrement encapsulée par la classe. Tous ses services devraient être étroitement alignés sur cette responsabilité. (Définition Wikipedia)

    «Responsabilité» = «raison de changer» changer quoi? «Une partie des fonctionnalités fournies par le logiciel» = unité de base

    Conclusion

    • Le principe de responsabilité unique s’applique aux unités de base -> fonctionne à un niveau bas

    • La séparation des préoccupations fonctionne à la fois aux niveaux les plus élevés et les plus bas

    • SRP et SoC travaillent ensemble pour séparer les préoccupations. Elles sont
      exactement le même à bas niveau

    La séparation des préoccupations est un processus; le principe de la responsabilité unique est une philosophie de conception / architecture. Ils ne sont pas complètement disjoints, mais ils servent des objectives différents.

    Similaire mais: SoC est lié aux préoccupations: pour résoudre un problème complexe en plusieurs préoccupations, SRP doit avoir une seule responsabilité.

    SRP et SOC travaillent à différents niveaux d’abstraction. Le but est dans les deux cas de réduire le couplage et de renforcer la cohésion. Alors que SRP fonctionne davantage au niveau object, SOC peut également travailler sur l’implémentation du niveau fonction. Une fonction peut être implémentée par un object mais aussi par plusieurs objects. Par conséquent, le couplage et la cohésion des deux principes peuvent différer.

    J’ai essayé de faire une comparaison entre la séparation des préoccupations (SoC) et le principe de la responsabilité unique (SRP).

    Différences

    • Le SRP est au niveau de la classe, mais SoC est dans chaque programme informatique, abstraction … ou parfois au niveau de l’architecture.

    • Le SRP concerne la qualité de (comment pas quoi) diviser votre domaine en classes cohérentes qui ont une seule responsabilité (une raison de changer). De l’autre côté, SoC est un principe de conception permettant de séparer un contexte en sections distinctes, de telle sorte que chaque section traite d’un problème distinct (et non comment), car il existe de nombreux outils (classes, fonctions, modules, etc.). ..) pour atteindre cet objective différents niveaux.

    • Le concept de SRP est basé sur la cohésion (haute cohésion), alors que SoC est proche de la Molécularité, divise et conquiert (D & C), … à chaque niveau d’abstraction.

    • Le SoC est un bon principe de conception pour faire face à la complexité, comme l’abstraction, alors que pour atteindre des classes responsables uniques, vous pouvez utiliser le principe du SoC comme une excellente solution. En tant que moyen de savoir qu’une classe a plus d’une responsabilité, c’est si vous pouvez extraire une autre responsabilité (préoccupation) de cette classe.

    Similitudes

    • Après avoir appliqué chacun de ces principes, votre contexte devient plus réutilisable, maintenable, robuste, lisible,….