Eu vejo o SRP não em relação a classe ter poucas funções, mas uma classe que tem · user1

Em resposta a Single Responsibility Principle - Exemplo Estranho

Eu vejo o SRP não em relação a classe ter poucas funções, mas uma classe que tem apenas uma motivação para mudar e isso se obtém quando a classe tem "poucas obrigações".

Por exemplo, veja o padrão Active Record, eu acho que esse padrão fere o SRP, pois a classe além de representar uma entidade do negócio como um User, a classe passa ter a responsabilidade de CRUD com o banco de dados.

Outro exemplo, uma classe Pedido quando é responsável por validar os dados, validar os itens, atribuir políticas de descontos, analisar a posição do estoque e etc. Já vi muitos casos do tipo, qualquer coisa que mude no negócio como a regra de descontos, seria motivo de alterar a classe Pedido. Definir esses processos em diferentes classes podem simplificar o processo e a compreensão do todo.

balavalda

1 ano atrás

Entendi, e seguir o SOLID seria sempre um "Gold Standart" ou depende de cada caso? Por que me parece que cada equipe ou projeto pode ter preferências ou pensamentos diferentes

user1

Autor

1 ano atrás

Assim como KISS, DRY e etc, o SOLID te dá uma diretriz de como pensar o seu código da maneira mais legível e manutenível possível. Mas não são regras para serem aplicadas a todo momento, ou até mesmo em todo o projeto.

Na verdade, tem um pessoal que tenta aplicar a todo custo esses princípios em todo lugar que o que alcança é justamente o contrário do objetivo. Por exemplo, o Single Responsibility Principle que você citou no começou, há pessoas que focam tanto na simplicidade das classes que o projeto fica tão fragmentado que acaba se tornando complexo.

Conheça esses conceitos, tente aplicar nos seus projetos, mas saiba que quem manda mesmo é o escopo do projeto use os padrões que se encaixam nessa realidade e não tente mudar a realidade para encaixar nesses padrões.