O SRP é perigoso (assim como a maioria dos princípios de design) se você o seguir como dogma. Minha perspectiva é respeitar o SOLID, mas cuidado com seu strong culto (ure), especialmente quando alguém está derramando mais calor do que luz citando esses princípios.
Quando leio sua pergunta, penso que o SRP está em oposição a YAGNI .
Usando seu exemplo de controlador, faz pouco sentido separar seu controlador em classes distintas se os requisitos nunca mudarem; você não estará mantendo o projeto após uma demonstração do "Shark tank", e / ou você nunca precisará reutilizar parte da lógica do seu controlador em outro projeto. Eles são todos grandes, talvez.
Robert Martin dá um exemplo detalhado usando o código em um projeto de boliche. O design leva a uma classe Game
que tem duas responsabilidades: controlar os quadros e calcular a pontuação.
No experimento de programação de programação em pares em seu livro, um dos desenvolvedores acabou sugerindo refatorar essas responsabilidades separadas em classes distintas, Game
e Scorer
, citando o SRP como a motivação. Um comentário sarcástico é feito de que os programadores do Linux gostam de fazer tudo em uma única função ilegível ...
É um bom exemplo do Ying e Yang do SRP. Ter módulos separados para as responsabilidades de Jogo e Pontuação tem a vantagem de permitir que os dois evoluam de forma mais independente, talvez até mesmo permitindo que um novo programador encontre onde no código esse erro complicado poderia ser (há menos linhas em Scorer
do que se todo o código fosse combinado em um módulo), etc. Essas classes poderiam teoricamente ser reutilizadas em outros aplicativos que precisam de seus serviços ( Jarts alguém?).
Mas há um lado negativo: antecipar mudanças que nunca ocorrerão é um desperdício de esforço. Que mudanças poderiam possivelmente chegar às regras do jogo de boliche! Teoricamente eles existem (ei, poderia haver uma ordem executiva de 45?) E se eles acontecessem, ter módulos separados certamente seria melhor então, certo?
Ah, YAGNI diz que não desperdice sua energia em mudanças até que elas cheguem. É engenharia excessiva.
Finalmente, o SRP (e o design orientado para a responsabilidade em geral) é uma heurística (o que parece ter funcionado no passado, mas não há garantia de que, aplicando-o, você se beneficiará). Ninguém fez pesquisas suficientes para lhe dizer quando vale a pena. Os problemas de design são difíceis e tentar usar um "princípio" dogmaticamente levará à decepção.
Eu achei o Wiki Princípios realmente interessante (embora incompleto) porque ele tenta mapear as relações entre esses vários princípios de design. Para o SRP, há muitos princípios relacionados, por exemplo, separação de interesses, lei de Curly, etc. . Lendo aqueles também ajudará você a entender os trade-offs.