Em muitos cartuns ou outras mídias, as forças do bem e do mal são freqüentemente ilustradas por um anjo e um demônio sentados nos ombros do personagem. Em nossa história aqui, em vez de bem e mal, temos SOLID em um ombro, e YAGNI (Você não vai precisar disso!) Sentado no outro.
Princípios sólidos aplicados ao máximo são mais adequados para sistemas empresariais enormes, complexos e ultra configuráveis. Para sistemas menores ou mais específicos, não é apropriado tornar tudo ridiculamente flexível, pois o tempo que você gasta abstraindo as coisas não será um benefício.
A passagem de interfaces, em vez de classes concretas, às vezes significa, por exemplo, que você pode facilmente trocar a leitura de um arquivo por um fluxo de rede. No entanto, para uma grande quantidade de projetos de software, esse tipo de flexibilidade simplesmente não é necessário, e você pode simplesmente passar classes de arquivos concretas e chamá-las por dia e poupar suas células cerebrais .
Parte da arte do desenvolvimento de software é ter uma boa noção do que provavelmente mudará com o passar do tempo e do que não é. Para as coisas que provavelmente mudarão, use as interfaces e outros conceitos do SOLID. Para as coisas que não, use o YAGNI e apenas passe tipos de concreto, esqueça as classes de fábrica, esqueça toda a conexão de tempo de execução e configuração, etc, e esqueça muitas das abstrações do SOLID. Na minha experiência, a abordagem YAGNI provou ser correta muito mais vezes do que não é.