Se sua classe tiver 20 parâmetros no construtor, não parece que sua equipe saiba exatamente o que é SRP. Se você tem uma classe que faz apenas uma coisa, como ela tem 20 dependências? Isso é como ir em uma viagem de pesca e trazendo uma vara de pesca, caixa de equipamento, suprimentos de quilting, bola de boliche, nunchucks, lança-chamas, etc .... Se você precisa de tudo isso para ir pescar, você não está indo apenas pescar.
Dito isto, o SRP, como a maioria dos princípios existentes, pode ser aplicado em excesso. Se você criar uma nova classe para incrementar inteiros, então sim, isso pode ser uma responsabilidade única, mas vamos lá. Isso é ridículo. Nós tendemos a esquecer que coisas como os princípios do SOLID existem para um propósito. O SOLID é um meio para um fim, não um fim em si mesmo. O fim é manutenibilidade . Se você pretende obter essa granularidade com o Princípio da Responsabilidade Única, é um indicador de que o zelo pelo SOLID cegou a equipe para o objetivo do SOLID.
Então, eu acho que o que estou dizendo é ... O SRP não é problema seu. É um mal-entendido do SRP ou uma aplicação incrivelmente granular dele. Tente fazer com que seu time mantenha a coisa principal como principal. E o principal é a manutenção.
EDITAR
Faça com que as pessoas projetem módulos de maneira a estimular a facilidade de uso. Pense em cada classe como uma mini API. Pense primeiro em "Como gostaria de usar essa classe" e implemente-a. Não pense apenas "o que essa classe precisa fazer". O SRP tem uma grande tendência para tornar as aulas mais difíceis de usar, se você não pensa muito sobre usabilidade.
EDIT 2
Se você está procurando dicas sobre refatoração, pode começar a fazer o que sugeriu - crie classes mais granuladas para envolver várias outras. Certifique-se de que a classe mais granulada ainda esteja aderindo ao SRP , mas em um nível mais alto. Então você tem duas alternativas:
- Se as classes mais refinadas não forem mais usadas em outras partes do sistema, você poderá gradualmente extrair sua implementação para a classe com granulação mais grossa e excluí-las.
- Deixe as classes mais refinadas sozinhas. Talvez eles foram bem concebidos e você só precisava do invólucro para torná-los mais fáceis de usar. Eu suspeito que este é o caso de grande parte do seu projeto.
Quando você terminar de refatorar (mas antes de se comprometer com o repositório), revise seu trabalho e pergunte a si mesmo se a sua refatoração foi realmente uma melhoria para a facilidade de manutenção e facilidade de uso.