Interfaces e indireção: Os problemas da OOP e do SOLID!

Sem dúvida, qualquer bom Programador já leu ou ouviu falar dos princípios S.O.L.I.D. certo?

• the Single responsibility principle (SRP),
• the Open-closed principle (OCP),
• the Liskov substitution principle (LSP),
• the Interface segregation principle (ISP), and
• the Dependency inversion principle (DIP).

OOP sem eles, é apenas uma confusão.

Porém, fica uma dúvida: Até onde são úteis? Sim, você me entendeu bem! Até quando devemos nos ater ferrenhamente aos princípios SOLID? Vale a pena em TODOS os casos?





Alguns artigos interessantes começaram a discutir isso e eu destaco dois:

• Revisiting SOLID principles, por Craig Berntson;
• Why I Don't Teach SOLID, por Brian Geihsler;

O primeiro até aponta alguns problemas do uso indiscriminado dos princípios SOLID, e levanta uma questão interessante:

"“When should I use SOLID and when should I not use SOLID?”

Well, Adam, the easy answer is always use SOLID, but as I discussed above, it doesn’t always make sense. Sometimes it adds complexity."

O segundo, é mais enfático:

"SOLID causes problems.  Problems big enough that warrant stowing it away in the attic.  When I used to champion SOLID, those who resisted would point to these problems.  I would dismiss these people as naysayers, resistant to change, or disinterested in code quality.  But now I've learned that they were right all along.  
"

Eu mesmo já postei inúmeros artigos defendendo os princípios SOLID, mas, até agora, não havia questionado seriamente sua utilização generalizada. Eu mesmo escrevi um artigo recente, onde questiono isso, embora não mencione diretamente o SOLID:

Por que investir tanto tempo construindo software?

Após militar muitos anos em Arquitetura e Qualidade de software, cheguei à conclusão de que nem sempre isso está certo. E então, uma verdade universal apareceu nos céus:

SOFTWARE É DESCARTÁVEL

Sim! Não digo o software básico, bem... talvez até ele... Mas o software que nós escrevemos e reescrevemos todo dia, deveria ser algo descartável, mais baseado em configuração do que codificação. Algo que pudéssemos substituir e descartar com facilidade, de modo a acompanhar a evolução socioeconômica e tecnológica atual.

Não acredita? Ok... Então vamos lá...

Você escreve classes, certo? Se programa em Java, então escreve classes PARA TUDO! Me diga com sinceridade: Por quê? Quantas dessas "classes" você estendeu? Quantas você reusou? Difícil responder, não?

E interfaces? Quantas interfaces você já escreveu? Por acaso isto aumentou a flexibilidade do seu software? Diminuiu significativamente o prazo de desenvolvimento?

E essa indireção toda? Em um moderno programa Java EE, tudo é embutido, encapsulado e indireto. Até coisas simples são difíceis de responder, por exemplo: "Como a app autoriza o usuário?"

E aí vem a questão que está "queimando meus miolos": Se eu tivesse optado por simplificar o código, em vez de usar OOP, frameworks e SOLID, será que teria sido mais eficiente?

Ao longo desta semana, mostrarei alguns artigos, com exemplos de código, para demonstrar que essas "pelancas" do software corporativo (OOP, SOLID e frameworks) talvez não sejam mais necessárias, e que precisamos repensar o custo disso tudo.

Até lá...

Ah, se você gostou desse artigo, vai adorar este: "YAGNI e as pelancas do software corporativo"

Cleuton Sampaio, M.Sc.