Confuso sobre o princípio de responsabilidade única no exemplo a seguir

Question

Na sequência vídeo, o autor faz uma classe existente e atribui o princípio de responsabilidade única a ele. Ele faz uma aula de impressão que tem o trabalho de acesso a dados, formatação e impressão do relatório. Ele interrompe cada método para sua própria classe, então cria uma classe DataAccess para lidar com o acesso a dados, ele cria uma classe ReportFormatter para lidar com a formatação do relatório e cria uma classe ReportPrinter para lidar com a impressão do relatório. A classe de relatório original é deixada com um método, print () que chama a impressão do método da classe do relatório. O DataAccess e o ReportFormatter parecem ter responsabilidade, mas o relatório depende do DataAcess e do ReportFormatter, então isso não quebra o SRP ou estou entendendo mal?

Answer 1

O princípio de responsabilidade única indica que uma determinada classe deve ter uma única responsabilidade (ou 'razão para mudar'). Por si só, não indica como essa responsabilidade é ser satisfeita. Fazer isso pode, e muitas vezes exige, a cooperação de várias outras classes como colaboradores.

Answer 2

Sem assistir ao vídeo, parece um design razoável. O SRP não está quebrado, pois os métodos que lidam com o acesso a dados não aparecem na classe ReportPrinter, apenas o conceito de que "eu posso chamar algo para obter os dados que desejo".

Você pode empurrá -lo um pouco mais longe e ter uma classe de coordenador responsável apenas por coordenar as atividades da classe de acesso a dados, a classe Formatter e a classe da impressora. Você também pode organizar os objetos de maneiras diferentes, como o coordenador envia dados para o formatador, que o envia para a impressora, e o coordenador não conhece (diretamente) sobre a impressora.

Algo precisa saber sobre a coordenação dos esforços dos objetos com foco rígido. Isso se torna sua responsabilidade. Não há problema em saber sobre a ideia ou conceito do que os outros objetos farão, desde que você não saiba ou se importe Como as eles fazem isto. Pensar nas interfaces como "costuras de responsabilidade" é um bom começo.

Também pode ser útil se você pensar nos objetos como passando dados um para o outro, em vez de "fazer" as coisas. Portanto, o relatório retorna (ou encaminha) um novo objeto que representa um relatório formatado, em vez de (conceitualmente) executar objetos em um relatório existente.

Answer 3

O SRP não aborda dependências. Inverter a classe nas classes de responsabilidade única facilitará a quebra dessas dependências posteriormente. O SRP aborda um dos dois princípios mencionados em conjunto: coesão e acoplamento. O SRP é sobre alta coesão, e as dependências podem ser indicativas de alto acoplamento. Bons projetos têm alta coesão e baixo acoplamento. Às vezes, esses dois princípios podem estar em desacordo.

Answer 4

Não. Ele não quebra SRP.

Assuma isso

DataAccess implements IDataAccess    

ReportFormatter  implements IReportFormatter 

ReportPrinter implements IReportPrinter 

Evento embora ReportPrinter relies on DataAccess and ReportFormatter , qualquer mudança no contrato de IDataAccess or IReportFormatter deve ser implementado por DataAccess and ReportFormatter respectivamente. ReportPrinter não se preocupa com as mudanças de responsabilidade nessas classes.

Você pode ter Composition ou implementar Mediador Padrão para fornecer acoplamento frouxo entre essas três classes e realizar o trabalho. Manter coupling afastar -se de responsibility.