Confundido sobre el Principio de responsabilidad única en el siguiente ejemplo

Question

En el siguiente video , el autor toma una clase existente y asigna el Single Principio de responsabilidad a la misma. Toma una clase de impresión que tiene el trabajo de acceder a datos, formatear e imprimir el informe. Él divide cada método en su propia clase, por lo que crea una clase DataAccess para manejar el acceso a datos, crea una clase ReportFormatter para manejar el formato del Informe y 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 ReportPrinter Print. DataAccess y ReportFormatter parecen tener la responsabilidad, pero ReportPrinter se basa en DataAcess y ReportFormatter, entonces, ¿esto no rompe el SRP o lo estoy malentendiendo?

Answer 1

El Principio de Responsabilidad Única indica que una clase dada debe tener una responsabilidad única (o 'razón para cambiar'). No indica, en sí mismo, cómo se debe satisfacer esa responsabilidad. Hacerlo puede, y a menudo requiere, la cooperación de muchas otras clases como colaboradores.

Answer 2

Sin mirar el video, parece 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".

Podría llevarlo un poco más lejos 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 puede organizar los objetos de diferentes maneras, como hacer que el coordinador envíe datos al formateador, que los envía a la impresora, y el coordinador no sabe (directamente) sobre la impresora.

Algo tiene que saber sobre la coordinación de los esfuerzos de los objetos de enfoque limitado. Eso se convierte en su responsabilidad. Está bien saber sobre la idea o el concepto de lo que harán los otros objetos, siempre y cuando no sepas o no te importe cómo lo hagan. Pensando en las interfaces como `` costuras de responsabilidad '' es un buen comienzo.

También puede ser útil si piensa que los objetos se pasan 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 3

SRP no aborda las dependencias. La división de la clase en clases de responsabilidad única facilitará la división de esas dependencias más adelante. SRP aborda uno de los dos principios del tema mencionados juntos: Cohesión y Acoplamiento. SRP se trata de una 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 reñidos.

Answer 4

No. No rompe SRP.

Suponga que

DataAccess implements IDataAccess    

ReportFormatter  implements IReportFormatter 

ReportPrinter implements IReportPrinter 

Evento aunque ReportPrinter se basa en DataAccess y ReportFormatter , cualquier cambio en el contrato de IDataAccess o IReportFormatter debe implementarse mediante DataAccess y ReportFormatter respectivamente. ReportPrinter no se preocupa por los cambios de responsabilidad en esas clases.

Puede tener Composition o implementar Mediator patrón para proporcionar acoplamiento entre estas tres clases y hacer el trabajo. Mantenga la parte del acoplamiento lejos de la responsabilidad .