Confundido sobre el Principio de Responsabilidad Individual en el siguiente ejemplo

Question

En el siguiente video, el autor toma una clase existente y le asigna el Principio de Responsabilidad Individual. Toma una clase de impresión que tiene el trabajo de acceder a datos, formatear e imprimir el informe. Él rompe cada método para su propia clase, por lo que crea una clase DataAccess para manejar el acceso de datos, se crea una clase ReportFormatter para manejar el formato del informe, y se crea una clase ReportPrinter para manejar la impresión del informe. La clase Report original se deja con un método, Print() que llama al método de clase PrintPrinter Print. DataAccess y ReportFormatter parecen tener la responsabilidad, pero se basa en ReportPrinter DataAcess y ReportFormatter, por lo que no se presente a romper el SRP o estoy entendiendo mal ¿verdad?

Answer 1

El principio de responsabilidad única indica que una clase determinada debe tener una sola responsabilidad (o 'razón para cambiar'). No indica, en sí mismo, cómo se debe cumplir esa responsabilidad. Hacerlo puede, y a menudo lo hace, requerir la cooperación de muchas otras clases como colaboradores.

Answer 2

SRP no se ocupa de las dependencias. Romper la clase en las clases de responsabilidad única facilitará romper esas dependencias más adelante. SRP aborda uno de los dos principios oftem mencionados juntos: cohesión y acoplamiento. SRP es de alta cohesión, y las dependencias pueden ser indicativas de un alto acoplamiento. Los buenos diseños tienen alta cohesión y bajo acoplamiento. A veces estos dos principios pueden estar en desacuerdo.

Answer 3

Sin ver el video, suena como un diseño razonable. SRP no está roto, ya que los métodos relacionados con el acceso a datos no aparecen en la clase ReportPrinter, solo el concepto de que "puedo llamar a algo para obtener los datos que quiero".

Puede empujarlo un poco más y tener una clase de coordinador responsable solo de coordinar las actividades de la clase de acceso a datos, la clase de formateador y la clase de impresora. También podría organizar los objetos de diferentes maneras, como tener el coordinador envía datos al formateador, que lo envía a la impresora, y el coordinador no (directamente) saber acerca de la impresora.

Algo tiene que saber sobre la coordinación de los esfuerzos de los objetos de enfoque restringido. Eso se convierte en su responsabilidad. Está bien saber acerca de la idea o concepto de lo que los otros objetos van a hacer, siempre y cuando no se conoce o cómo lo hacen. Pensar en las interfaces como "vetas de responsabilidad" es un buen comienzo.

También puede ser útil si considera que los objetos se transmiten datos entre sí, en lugar de "hacer" cosas. Por lo tanto, ReportFormatter devuelve (o reenvía) un nuevo objeto que representa un informe formateado, en lugar de (conceptualmente) realizar objetos en un informe existente.

Answer 4

No. No se rompe SRP.

Supongamos que

DataAccess implements IDataAccess  

ReportFormatter implements IReportFormatter 

ReportPrinter implements IReportPrinter 

Evento embargo ReportPrinter relies on DataAccess and ReportFormatter, cualquier cambio en el contrato de IDataAccess or IReportFormatter debe ser implementada por DataAccess and ReportFormatter respectivamente. ReportPrinter no se preocupa por los cambios de responsabilidad en esas clases.

Puede tener Composition o implementar el patrón Mediator para proporcionar un acoplamiento flexible entre estas tres clases y realizar el trabajo. Mantenga coupling parte de responsibility.