On BA Chapter 13 (OO vs Functional)

Roughly, the differences between functional and objected oriented programming can be summed up as follows: In object oriented programming everything is treated as an object that has state and behavior. Among others this offers modularity and information hiding. In functional programming one is using a set of functions each of which performing a task. Selectively executing these function results in the solution to the problem at hand. While one of OO's first principles is modularity, functional programming is also achieving modularity, by means of systematic use of stateless functions, high level functions (e.g. combinators), lists and other recursively defined types, as well as lazy evaluation. However this is only fine-grain modularization. Functional programming seems to have no contribution to large-grain modularity, which pertains to software architecture.

The author thinks that the stateless nature of functional programming does not seem to affect in any way software architecture. While I agree with this thought, I also feel that this mostly applies to the development view of the 4+1 views. In the process and physical view however, being stateless may become an important feature. This is because purely functional programs have no side effects, which makes them trivially parallelizable. Nevertheless, by looking at how a _good_ functional program is written (e.g. as a set of modules that are not dependent on each other), in the development view it almost feels like it is designed with object oriented principles in mind.

Proponents of functional programming believe that having functions as first-class citizens lets you find more opportunities for abstraction, which means your code is smaller, tighter, more reusable, and more scalable. But having functions as first class citizens can be achieved in OO as well. However, since in the OO context, the only first-class citizens are, at runtime, objects, corresponding in the static structure to classes, a new construction has been designed: the notion of agents. An agent is an object representing a feature of a certain class, ready to be called. Following a parallel with functional languages, agents are high level routine objects; that is the equivalent of combinators (high level functions).

Reusability and dynamic binding are some aspects where OO excels. Depending on the problem, owe to commonalities captured by inheritance, the number of feature definitions may be significantly smaller in OO as if one were to implement the same problem in a functional language. By collecting the features applicable to many variants into correct abstract data types and grouping them toward the top of the inheritance hierarchy, one can benefit from effective code reduction. There seems to be no equivalent to inheritance in functional programming, where it is required to define the variant of every operation for every combinator, repeating any common ones. Dynamic binding is also essential with OO, because it removes the need for client classes to perform multibranch discriminations to perform operations. Dynamic binding solves what traditionally used to be a major source for architecture degradation and obsolescence.

After reading the chapter, my thoughts converge with those of the author’s, that OOD in his modern form, subsumes the functional approach, retaining its benefits while providing more alternatives for extension and reuse.