Aide à la compréhension du principe de la responsabilité unique

Question

J'essaie de comprendre ce qu'est réellement une responsabilité, alors je veux utiliser un exemple de quelque chose sur lequel je travaille actuellement. J'ai une application qui importe des informations sur les produits d'un système à un autre. L'utilisateur des applications peut choisir différents paramètres pour quels champs de produit dans un système qui veulent utiliser dans l'autre système.

J'ai donc une classe, disons ProductImporter et sa responsabilité est d'importer des produits. Cette classe est grande, probablement trop grande.

Les méthodes de cette classe sont complexes et seraient, par exemple, getDescription. Cette méthode n'obtient pas simplement une description de l'autre système mais définit une description de produit basée sur divers paramètres définis par l'utilisateur. Si je devais ajouter un paramètre et une nouvelle façon d'obtenir une description, cette classe pourrait changer.

Alors, est-ce deux responsabilités? Y en a-t-il un qui importe des produits et un qui en obtient une description? Il semblerait que de cette façon, presque toutes les méthodes que j'utiliserais seraient dans sa propre classe et cela semble être exagéré.

J'ai vraiment besoin d'une bonne description de ce principe car il m'est difficile de le comprendre complètement. Je ne veux pas de complexité inutile.

Answer 1

La «responsabilité» est définie dans ce principe comme une raison de changer. Dans ce cas, la seule responsabilité de votre classe serait d'importer des produits. Si la manière d'importer des changements de produit, alors la classe devrait changer.

L'intention est d'éviter que des choses différentes changent la même classe en même temps. Par exemple, si votre classe d'importateur de produits a également défini son format de sortie, il aura alors deux responsabilités, car il est probable que le format de sortie est totalement indépendant du mécanisme d'importation des données.

Maintenant, que la classe est énorme et que getDescription() définit également une description ne sont pas une violation directe de la SRP, mais de principes différents. A savoir, vous devriez éviter d'avoir des classes énormes (montre un manque de conception) et chaque méthode devrait faire une seule chose (ce qui serait une sorte de version plus concrète de la SRP.)