Software Architecture: Object-Oriented versus Functional

This chapter of Beautiful Architecture compares the architectural benefits of functional and Object-Oriented languages. It is written by an open OO-proponent and this shines through even though he (at least claim) to do an hones effort of staying neutral. Most paragraphs takes one functional programming usage from the cited paper on functional programming and argues that it can be done as well or better using Object-Oriented approaches and types. In the end the author also argues for agents/closures/delegates stating they are a natural extension to Object-Oriented technology that we can and should steal from the functional world. This seems to be in line with my comment in an earlier blog. Instead of functional programming marching to the forefront, they instead presently seem to serve as a source of influence for imperative programming languages who are subsuming many of their concepts. I'm sure it must be a bit frustrating for some long-time functional programming purists to see their ideas being assimilated into their imperative rivals instead of seeing their languages win out, but that is another issue altogether.

Reading the parts about modularity and extensibility I thought the author was relying too much on inheritance. Modularity is not solely expressed through types, but also through the composition of these In fact my biggest takeaway from the design patterns book was not a particular pattern but the notion of "Favor composition". Inheritance leads to very strong bindings and which makes it hard if you ever need to change the hierarchy. In addition an inheritance hierarchy will strongly embed one particular decomposition into your application which lends itself to a stronger tyranny of the dominant decomposition. Since there are usually many possible decompositions of one domain we should avoid infusing any one more into our applications than we have to in case we have to change it. The point with OO was to model the world, not to solve every problem through type hierarchies and I do not think that always extending the functionality by finding the place in the type hierarchy where the change fits and inserting it there through inheritance is a good idea. In addition I do not really like multiple inheritance as I feel it weakens the is-a intuition of inheritance and lead to very rigid design structures with tight coupling.

As I mentioned above the final part talks about agents and I found this part the most interesting of the chapter. They describe agents as a way to infuse a class with new functionality at runtime, explaining how it cleanly replaces visitor which is used in compilers, etc. I find this way of looking at it enlightening as this is usually exactly what we want to do with task and data oriented libraries such as ParallelArray and ForkJoin. We want to infuse a task class with new functionality, which is the code we want it to run in a separate thread of execution. This is to me a stronger argument for such structures than replacing visitor as I believe this usage pattern will often be needed in the future.

To conclude, even though I disagree with the chapter on some finer points and feel that the author is fairly biased even though he makes a conscious effort not to be, I believe I agree with his final conclusion. To answer one of JLSjr's questions I do prefer the analogy to the real world of Object-Oriented technology to the mathematical foundation of functional programming for most problems. After all most of our software is written to support real world processes and not to perform mathematical calculations.