函数分解真的是反模式吗？

当我阅读您遇到的最糟糕的反模式时，我单击了这篇文章中的链接以登陆有关反模式的网站。

而http://sourcemaking.com/antipatterns/functional-decomposition页让我疑惑。

这个反模式有多严重，它到底是反模式吗？因为，尽管我现在主要进行OOP编程，但我仍然不愿意反对纯Java的所有OOP语言以及它们带来的设计实践。而且我猜想，我在编写代码时仍具有函数式编程的一些特征。

这就提出了一个问题，我是坚持OOP + Functional风格做错了吗，还是在行业中很常见，实际上还不是那么糟糕。

我从经验中知道的是，OOP +功能样式与纯OOP开发人员并不完全兼容。但是，与此同时，尽管OOP开发人员在OOP +功能开发方面遇到问题，但反驳的是，OOP解决方案往往设计过度，难以使用，并且根据我的经验，甚至一点也不容易，实际上介绍了一些非常严重的错误可以隐藏的盲点。

因此，即使我与同事讨论了这些主题，但我得出的结论是，所有方法实际上都不是完美的。而且我仍然有未解决的问题。

另一个线程中来自另一个帖子的链接也加剧了OOP问题。链接着眼于Java风格的OOP http://chaosinmotion.com/blog/?p=622

那么将函数式编程与OOP混合的一般态度是什么？开发人员应努力实现什么平衡？

首先，函数式编程是当前所有酷孩子正在做的事情。反模式实际上是在谈论过程编程（如果将该技术称为“过程分解”，则更为清楚，但事实并非如此），我想您也是。

反模式谈论了用面向对象语言编写过程代码的不良方式，另一页谈论了不良的做法是编写Java-实际上，没有一种语言如此奇妙，您可以做任何想做的事情，但是做不到写不好的代码。

在实践中，与面向过程的代码相比，面向对象的代码具有更多的工程设计-在工程设计方面更少，在工程设计方面更多。

在您的情况下，这取决于具体情况，我不确定您实际上以程序化方式做什么。它是否正确，清晰，可测试，易于修改等？判断代码的标准应基于这种实际的考虑，而不是基于一种特定样式的纯度。在您的情况下，听起来像是理性和知识渊博的人可能会不同意（并同意！），如果这样的话，可能没有客观的方法可以确定问题的真相。