A decomposição funcional é realmente um antipadrão?

Enquanto eu estava lendo Os piores anti-padrões que você encontrou , cliquei no link deste post para acessar o site sobre anti-padrões.

E a página http://sourcemaking.com/antipatterns/functional-decomposition me fez pensar.

Quão ruim é esse anti-padrão, e é um anti-padrão? Porque, embora atualmente esteja fazendo principalmente programação OOP, ainda sinto uma relutância em relação a linguagens OOP-puras, como Java, e também às práticas de design que elas trazem. E eu acho que ainda tenho algumas características da programação funcional enquanto escrevo o código.

E isso trouxe à tona uma questão: estou fazendo errado ao adotar o estilo OOP + Funcional ou é comum na indústria e não é tão ruim assim.

O que sei por experiência própria é que o estilo OOP + Funcional não é completamente compatível com desenvolvedores puros de OOP. Mas, ao mesmo tempo, enquanto os desenvolvedores de OOP têm problemas com o desenvolvimento de OOP + Funcional, o contra-argumento é que as soluções de OOP são muitas vezes super-projetadas e difíceis de usar, e, pela minha experiência, não eram nem um pouco mais fáceis e realmente introduziu alguns pontos cegos para erros MUITO sérios ocultos.

Portanto, mesmo tendo discutido com meu colega sobre esses tópicos, cheguei à conclusão de que nenhuma das maneiras é realmente perfeita. E ainda tenho a pergunta sem resposta.

O problema OOP também foi reforçado por um link de outra postagem no mesmo segmento. O link analisa o estilo Java OOP http://chaosinmotion.com/blog/?p=622

Então, qual é a atitude geral em relação à mistura de programação funcional com OOP? E qual é o equilíbrio que um desenvolvedor deve se esforçar para alcançar?

Antes de tudo, a programação funcional é atualmente o que todas as crianças legais estão fazendo. O Anti-Pattern estava falando realmente de programação procedural (seria mais claro se a técnica fosse chamada de "decomposição processual", mas não é), e acho que você também.

O anti-padrão falava sobre maneiras ruins de escrever código procedural em uma linguagem orientada a objetos, a outra página falava sobre mal era escrever Java - na verdade, não há linguagem tão fantástica que você possa fazer tudo o que quiser, mas não pode escreva código incorreto.

Na prática, eu vi um pouco mais de engenharia em código orientado a objetos do que em procedimentos - um pouco menos em engenharia e um pouco mais em engenharia.

No seu caso, isso dependeria dos detalhes, e não tenho certeza do que você realmente faz em um estilo processual. É correto, claro, testável, fácil de modificar, etc? Os critérios para julgar o código devem se basear em preocupações práticas, e não na pureza de um estilo específico. Parece que, no seu caso, pessoas razoáveis ​​e conhecedoras podem discordar (e fazer!) Sobre essas preocupações e, nesse caso, provavelmente não há uma maneira objetiva de determinar a verdade do problema.