機能分解は本当にアンチパターンですか？

私が読んだ最悪のアンチパターンを読んでいるときに、この投稿のリンクをクリックして、アンチパターンに関するWebサイトにアクセスしました。

そして、http：//sourcemaking.com/antipatterns/functional-decompositionのページは私に不思議に思いました。

このアンチパターンはどれほどひどいですか、それともアンチパターンですか？今日私はほとんどOOPプログラミングを行っていますが、Javaのような純粋なOOPのすべての言語や、それらがもたらす設計慣行にもまだ気が進まないためです。コードを書いている間も、関数型プログラミングにはいくつかの特徴があります。

そして、これは質問を持ち出しました、私はOOP + Functionalスタイルに固執することによって間違っていますか、それとも業界では一般的であり、実際にはそれほど悪いことではありませんか？

私が経験から知っていることは、OOP + Functionalスタイルは純粋なOOP開発者と完全には互換性がないということです。しかし、同時に、OOP開発者はOOP +機能開発に問題を抱えていますが、反対意見は、OOPソリューションは非常に頻繁に設計されすぎて使用が困難であり、私の経験から、少しも簡単ではなく、実際には非常に深刻なバグを隠すためにいくつかの盲点を導入しました。

したがって、これらのトピックについて同僚と話し合ったとしても、どの方法も実際には完璧ではないという結論に達しました。そして、私はまだ質問に答えられていません。

OOP問題は、同じスレッド内の別の投稿からのリンクによっても強化されました。リンクは、JavaスタイルのOOP http://chaosinmotion.com/blog/?p=622にあります。

では、関数型プログラミングとOOPを混合することに対する一般的な態度はどのようなものでしょうか。そして、開発者が達成するために努力すべきバランスは何ですか？

まず第一に、関数型プログラミングは現在、すべてのクールな子供たちがやっていることです。Anti-Patternは実際に手続き型プログラミングについて話していました（この手法を「手続き型分解」と呼べばより明確になりますが、そうではありません）。あなたもそうだったと思います。

アンチパターンは、オブジェクト指向言語で手続き型コードを書く悪い方法について話しました、もう一方のページは、Javaを書くことについて話しました-実際には、やりたいことをすべて実行できるほど素晴らしい言語はありませんが、できない悪いコードを書いてください。

実際には、手続き型よりもオブジェクト指向コードでのエンジニアリングの方が少し見られます。エンジニアリングの下で​​は少し少なく、エンジニアリングの上では少し多くなります。

あなたの場合、それは詳細に依存します、そしてあなたが実際に手続き型で何をしているのかわかりません。正しく、明確で、テスト可能で、修正が容易か、など。コードを判断する基準は、特定のスタイルの純粋さではなく、そのような実際的な懸念に基づいている必要があります。あなたの場合、合理的で知識のある人々がそれらの懸念について反対する（そしてそうする！）可能性があるように聞こえます。