web-dev-qa-db-fra.com

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

a) Quelle est la différence entre SRP et SOC? Peut-être que [~ # ~ # ~] SRP [~ # ~ ~] est appliqué au niveau de la classe, tandis que SOC peut être appliqué au système , Sous-système , Module , classe ou fonction niveaux.

b) Si réponse à a) est oui, est alors SOC appliqué au niveau de la classe Un synonyme de SRP ?

merci

design-patternssingle-responsibility
19
user1483278

Le principe de responsabilité unique concerne votre code ne faisant que 1 chose et vous pouvez diviser toutes les fonctionnalités dans plusieurs classes que toutes sont conçues pour faire 1 chose spécifique. Un exemple est une classe spécifique pour la validation, de faire une logique professionnelle, enrichissant un modèle, de récupérer des données, de mettre à jour des données, de navigation, etc.

La séparation des préoccupations concerne votre code n'étant pas étroitement couplé à d'autres classes/systèmes. L'utilisation d'interfaces dans votre code aide beaucoup, de cette façon, vous pouvez affûter des classes/systèmes à votre code. Un plusside sur ceci est qu'il est plus facile de tester votre code aussi. Il y a beaucoup de cadres (CIO) qui peuvent vous aider à y parvenir, mais vous pouvez implémenter une telle chose vous-même bien sûr.

Un exemple de quelque chose de soc, mais pas de SRP

public class Foo
{
    private readonly IValidator _validator;
    private readonly IDataRetriever _dataRetriever;

    public Foo(IValidator validator, IDataRetriever dataRetriever)
    {
        _validator = validator;
        _dataRetriever = dataRetriever;
    }

    public NavigationObject GetDataAndNavigateSomewhereIfValid()
    {
        var data = _dataRetriever.GetAllData();

        if(_validator.IsAllDataValid(data))
        {
            object b = null;
            foreach (var item in data.Items)
            {
                b = DoSomeFancyCalculations(item);
            }

            if(_validator.IsBusinessDataValid(b))
            {
                return ValidBusinessLogic();
            }
        }
        return InvalidItems();
    }

    private object DoSomeFancyCalculations(object item)
    {
        return new object();
    }
    private NavigationObject ValidBusinessLogic()
    {
        return new NavigationObject();
    }

    private NavigationObject InvalidItems()
    {
        return new NavigationObject();
    }
}

Comme vous pouvez le constater, ce code n'est pas étroitement couplé aux classes ou autres systèmes, car il n'utilise que certaines interfaces pour faire des choses. C'est bon d'un point de vue de la SOC.

Comme vous pouvez le constater, cette classe contient également 3 méthodes privées qui font des trucs fantaisistes. D'un point de vue SRP, ces méthodes devraient probablement être placées dans certaines classes de leurs propres cours. 2 d'entre eux font quelque chose avec la navigation, qui correspondrait à une classe d'inavigation. L'autre fait certains calculs de fantaisie sur un article, cela pourrait probablement être placé dans une classe ibusinessLogic.

Avoir quelque chose comme ça, vous avez tous les deux le SOC et SRP en place:

public class Foo
{
    private readonly IValidator _validator;
    private readonly IDataRetriever _dataRetriever;
    private readonly IBusinessLogic _businessLogic;
    private readonly INavigation _navigation;

    public Foo(IValidator validator, IDataRetriever dataRetriever, IBusinessLogic businessLogic, INavigation navigation)
    {
        _validator = validator;
        _dataRetriever = dataRetriever;
        _businessLogic = businessLogic;
        _navigation = navigation;
    }

    public NavigationObject GetDataAndNavigateSomewhereIfValid()
    {
        var data = _dataRetriever.GetAllData();

        if(_validator.IsAllDataValid(data))
        {
            object b = null;
            foreach (var item in data.Items)
            {
                b = _businessLogic.DoSomeFancyCalculations(item);
            }

            if(_validator.IsBusinessDataValid(b))
            {
                return _navigation.ValidBusinessLogic();
            }
        }
        return _navigation.InvalidItems();
    }
}

Bien sûr, vous pouvez débattre si toute cette logique doit être placée dans la méthode GetDataAndNavigateSomewhereIfValid. C'est quelque chose que vous devriez décider pour vous-même. Pour moi, cela ressemble à cette méthode fait trop de choses.

13
Jan_V

Comme pour SRP étant appliqué uniquement au niveau de la classe, dans ses livres, Robert C. Martin (autant que je sache, il vulgarisait s'il n'est pas proposé le concept) États:

Clean Code, page. 138 : "Le principe de responsabilité unique (SRP) indique qu'une classe ou un module devrait en avoir une, et une seule, raison de changer."

dans les principes agiles, les modèles et les pratiques en C #, page 116 : "[...] et relier la cohésion aux forces qui cause une module ou une classe, changer. "

met l'accent sur le mien.

Dans [~ # ~] APPP [~ # ~] Il parle plus de longueur à propos de SRP et axé presque entièrement au niveau de la classe. Bien qu'il semble se concentrer sur le niveau de la classe, je pense que le principe est également dirigé vers des modules et d'autres constructions de niveau supérieur.

Pour une telle raison, je ne qualifierais pas SRP en tant que SOC au niveau de la classe comme vous le suggérez dans votre question.

2
Gilles

Voici ma compréhension de ces principes.

Séparation des préoccupations (SOC) - Il s'agit d'une division d'un système de logiciel en modules plus petits, chacun sur ces modules est responsable d'une seule préoccupation. Une préoccupation, dans ce cas, est une caractéristique ou un cas d'utilisation d'un système logiciel. Un module a une API bien définie (interface) en conséquence, ce qui rend tout le système hautement cohésif. Il existe deux types principaux: horizontal et vertical.

Principe de responsabilité unique (SRP) - est un principe de conception qui indique que chaque bloc de construction (il peut s'agir d'une classe, d'un module, d'un objet ou même d'une fonction) d'un système ne devrait avoir qu'une seule responsabilité. Robert C. Martin. Martin décrit une responsabilité comme une raison de changer. En général, il est beaucoup préférable d'avoir une seule classe/objet qui a la responsabilité sur une seule partie de la fonctionnalité au lieu de pouvoir exécuter beaucoup de fonctions, parfois même non liées, à rendre cette classe grande et étroitement couplée, ainsi appelé "dieu objet".

De plus, j'ai décrit ces principes dans des détails plus importants dans mon poteau de blog, s'il vous plaît jeter un oeil.

https://crosp.net/blog/software-architecture/srp-soc-andrid-settings-example/

0
CROSP

Ici, vous pouvez trouver une courte vidéo expliquant clairement la différence entre ces terminologies. https://www.youtube.com/watch?v=c7hkrv1oasy

Séparation des préoccupations (SOC). Divisez votre application en fonctionnalités distinctes avec aussi peu de chevauchement dans la fonctionnalité que possible. (Microsoft).

"Concern" = "fonctionnalité distincte" = "section distincte"

"Préoccupation" fonctionne à des niveaux élevés et bas

principe de responsabilité unique Soute que chaque module ou chaque classe devrait avoir la responsabilité sur une seule partie de la fonctionnalité fournie par le logiciel et que la responsabilité devrait être entièrement encapsulée par la classe. Tous ses services devraient être étroitement alignés sur cette responsabilité. (Définition de Wikipedia)

"responsabilité" = "raison de changer"

changer quoi? "Une seule partie de la fonctionnalité fournie par le logiciel" = unité de base

Conclusion

Principe de responsabilité unique fonctionne sur les unités de base -> fonctionne à bas niveau

La séparation des préoccupations fonctionne à des niveaux élevés et bas

SRP et SOC travaillent ensemble pour la séparation des préoccupations. Ils sont exactement les mêmes à bas niveau

0
Marco Crispino