Confus à propos du principe de responsabilité unique dans l'exemple suivant

Question

Dans la vidéo ci-dessous, l'auteur prend une classe existante et attribue la classe Single. Principe de responsabilité à elle. Il prend une classe d'impression chargée de l'accès aux données, du formatage et de l'impression du rapport. Il divise chaque méthode en sa propre classe. Il crée donc une classe DataAccess pour gérer l'accès aux données, une classe ReportFormatter pour gérer la mise en forme du rapport et crée une classe ReportPrinter pour gérer l'impression du rapport. La classe Report d'origine se retrouve alors avec une méthode, Print (), qui appelle la méthode class de ReportPrinter, Print. DataAccess et ReportFormatter semblent avoir des responsabilités, mais ReportPrinter s'appuie sur DataAcess et ReportFormatter. Par conséquent, cela ne rompt-il pas le SRP ou est-ce que je le comprends mal?

Answer 1

Le principe de responsabilité unique indique qu’une classe donnée doit avoir une responsabilité unique (ou "raison de changer"). Cela n'indique pas en soi comment cette responsabilité doit être remplie. Cela peut, et nécessite souvent, la coopération de plusieurs autres classes en tant que collaborateurs.

Answer 2

Sans regarder la vidéo, cela ressemble à une conception raisonnable. SRP n'est pas rompu, car les méthodes traitant de l'accès aux données n'apparaissent pas dans la classe ReportPrinter, mais uniquement selon le concept "je peux appeler quelque chose pour obtenir les données que je veux".

Vous pouvez pousser un peu plus loin et avoir une classe de coordinateur chargée uniquement de coordonner les activités de la classe d'accès aux données, de la classe de formatage et de la classe d'imprimante. Vous pouvez également organiser les objets de différentes manières, par exemple si le coordinateur envoie des données au formateur, qui les envoie à l'imprimante, sans que le coordinateur connaisse directement l'imprimante.

Il faut savoir quelque chose à propos de la coordination des efforts des objets étroitement focalisés. Cela devient leur responsabilité. Il n’est pas difficile de connaître l’idée ou le concept de ce que feront les autres objets, tant que vous ne savez pas ou ne vous souciez pas de la façon dont ils disposent. Considérer les interfaces comme des "coutures de responsabilité" est un bon début.

Cela peut également être utile si vous considérez des objets comme se transmettant des données les uns aux autres, plutôt que de "faire". des choses. Ainsi, ReportFormatter renvoie (ou transmet) un nouvel objet représentant un rapport mis en forme, plutôt que d'exécuter (de manière conceptuelle) des objets sur un rapport existant.

Answer 3

SRP ne traite pas les dépendances. Diviser la classe en classes à responsabilité unique facilitera la suppression ultérieure de ces dépendances. SRP aborde l'un des deux principes mentionnés ensemble: la cohésion et le couplage. Le SRP est à propos de la cohésion élevée, et les dépendances peuvent indiquer un couplage élevé. Les bonnes conceptions ont une forte cohésion et un faible couplage. Parfois, ces deux principes peuvent être contradictoires.

Answer 4

Non. Cela ne rompt pas le SRP.

Supposons que

DataAccess implements IDataAccess    

ReportFormatter  implements IReportFormatter 

ReportPrinter implements IReportPrinter 

Événement bien que ReportPrinter s'appuie sur DataAccess et ReportFormatter , toute modification du contrat de IDataAccess ou IReportFormatter doit être implémentée par DataAccess et ReportFormatter respectivement. ReportPrinter ne s'inquiète pas des changements de responsabilité dans ces classes.

Vous pouvez avoir Composition ou implémenter le modèle Mediator pour fournir des informations en vrac. couplage entre ces trois classes et faire le travail. Éloignez la partie couplage de la responsabilité .