Estou lendo um novo livro e me chamou a atenção que em suas primeiras páginas há um ataque direto a programação orientada a objetos, com intuito de valorizar a programação funcional. O livro se chama “Programação Funcional para Desenvolvedores Java” do autor Dean Wampler e acima está uma imagem de sua capa.
Nesse post vou abordar resumidamente dois dos primeiros pontos que orientação a objetos se torna ineficiente e que são apontados pelo autor: Reuso e Prazo.
Reuso, Modularidade e a Orientação a Objetos
A programação orientada a objetos surgiu com uma das grandes armas para modularizar partes do sistema para que assim possam ser reutilizadas, economizando tempo no desenvolvimento.
A flexibilidade quase sem limite dos objetos na verdade mina o potencial de reuso, porque há poucos padrões sobre como os objetos deve se interconectar e não conseguimos chegar a um acordo nem sobre nomes básicos para as coisas.
Mas, como afirmado pelo autor, esse objetivo não foi alcançado completamente. A flexibilidade trazida pelos objetos forçou o mundo do desenvolvimento a definir alguns padrões para que o código não acabasse em uma maior complexidade ou miscelânea. Mas não há padrões estipulados para todas as situações vividas durante um desenvolvimento orientado a objetos.
Com relação a padrões, cada uma das APIs que conseguiram se tornar reutilizáveis e ficaram famosas como o JDK, Spring Frameworkentre outras, possuem seus próprios padrões que devemos estudar, compreender e estar em conformidade com eles durante a nossa codificação.
Prazos e a Orientação a Objetos
Ainda entre as páginas 17 e 18 encontrei uma afirmação a respeito da ineficiencia da programação orientada a objetos diantes do mercado atual, que exige rapidez na entrega. O autor diz que diante dos cronogramas apertados o que o mercado espera é a entrega rápida de algo que seja valioso para ele, independente se o domínio está corretamente entendido ou não, já que esse será descoberto e modificado de acordo com as entregas. Com a desvalorização do entendimento e modelagem do domínio e da valorização da rapidez do desenvolvimento, a orientação a objetos passa a ser questionável.
Quando os cronogramas eram mais longos, fazia mais sentido modelar seu domínio cuidadosamente e implementá-lo em código. Se você cometesse um erro, levaria meses para corrigí-lo com uma nova versão. Atualmente, na maioria dos projetos, entender o domínio com precisão é menos importante do que entregar alguma coisa valiosa rapidamente. Nossa compreensão do domínio mudará rapidamente, de qualquer forma, à medida que nós e nossos clientes descobrimos mais coisas a cada instalação. Se entendermos mal algum aspecto do domínio, podemos consertar esses errors rapidamente quando fazermos instalações frequentes.
Se a modelagem cuidadosa parace menos importante, a implementação conscienciosa do modelo de objetos é ainda mais suspeita atualmente do que no passado. Embora o Agile SoftwareDevelopment (Desenvolvimento Ágil de Software) tenha melhorado bastante nossa qualidade e capacidade de responder a mudanças, precisamos repensar formas de manter nossos códigos “minimamente suficiente” para os requisitos atuais, mas ainda assim flexível a mudanças. A programação funcional nos ajuda a fazer isso. – Dean Wampler
O desenvolvimento ágil de software traz uma solução para tal situação acrescendo a qualidade do processo de desenvolvimento, mas Dean Wampler afirma que a forma de codificação ainda assim necessita ser repensada, que é o propósito da Programação Funcional.
Tássio Auad 