Is functional decomposition really an antipattern?

Question

While I was reading The worst anti-patterns you have came across, I clicked on the link in this post to land on the web site about anti-patterns.

And the http://sourcemaking.com/antipatterns/functional-decomposition page got me wondering.

How bad this anti-pattern is, and is it an anti-pattern at all? Because, although I am doing mostly OOP programming nowadays, I still feel a reluctance against pure OOP-everything languages like Java, and also the design practices that they bring. And I guess, I still have some traits of the functional programming while I write the code.

And this brought up a question, am I doing wrong by sticking to OOP+Functional style, or is it common in industry and is not actually that bad.

What I do know from experience, is that OOP+Functional style is not completely compatible with pure OOP developers. But at the same time, while OOP developers have problems with OOP+Functional development, the counterargument is that OOP solutions are quite often over-engineered and too hard to use, and from my experience, were not even a single bit easier, and actually introduced some blind spots for VERY serious bugs to hide.

So, even though I had discussion with my colleague about these topics, I came to conclusion that none of the ways is actually perfect. And I still have the question unanswered.

The OOP problem was also reinforced by a link from another post in the same thread. The link looks at the Java style OOP http://chaosinmotion.com/blog/?p=622

So what is the general attitude toward mixing functional programming with OOP? And what is the balance a developer should strive to achieve?

Answer 1

First of all, functional programming is currently what all the cool kids are doing. The Anti-Pattern was talking about procedural programming really (it would be clearer if the technique were called "procedural decomposition" but it's not), and I think you were too.

The anti-pattern talked about bad ways of writing procedural code in an object oriented language, the other page talked about bad was of writing Java - in truth there is no language so fantastic that you can do everything you want to do but can't write bad code.

In practice, I've seen a little more engineering in object oriented code than procedural -a little less under engineering and a little more over engineering.

In your case, it would depend on the specifics, and I'm not sure what you actually do in a procedural style. Is it correct, clear, testable, easy to modify, etc? The criteria to judge the code should be based on such practical concerns, and not on purity of one particular style. It sounds like in your case reasonable and knowledgeable people could disagree (and do!) about those concerns, and if so there is probably no objective way to determine the truth of the matter.