[Home] [Articles, Categories, Tags] [Books, Quotes]
Object Oriented Versus Functional Programming
Author:
Pub Year:
Source:
Read: 2018-08-20
Last Update: 2018-08-20

Five Sentence Abstract:

The book opens with a short introduction that tries to bring the two competing programming philosophies together. Next a whirlwind tour of the lambda function is covered from the perspective that you already have a solid grasp of general programming principles. The SOLID principles are shown to be complementary or even reinterpretations of functional programming aspects; the strongest example in my opinion was showing that Liskov principle is superfluous in functional programming and, as the 'compose don't inherit' line of reasoning is adopted by object-oriented programmers, it is (slowly) losing its place in the object-oriented world. Two design patterns, command and strategy, are shown to be nothing more than clumsy implementations of functional programming; instead of creating extra classes and interfaces, you can simply pass in functions (as long as they are first-class citizens) to constructors at runtime. The conclusion is that the future of programming languages is neither functional nor object-oriented, but hybrid.

Thoughts:

This is barely a book and more of a report, weighing in at only about 40 pages. Still, it manages to pack some thought provoking concepts into a small space.

There is no proselytizing of either object oriented or functional programing, but rather shows that there is quite a lot of overlap between the two, despite the animosity between the two camps.

The most interesting thing I took away, and it is obvious in hindsight, is that a some of the design patterns championed by object oriented designers are nothing more than clumsy implementations of functional programming. For example the command and strategy patterns can be greatly simplified by using lambda functions to replace the boilerplate classes needed for each 'action'.

Treating functions as first class citizens allows you to pass them straight into the class when it is constructed instead of using an interface that takes another class to determine functionality.

The example was a compression class that would allow you to compress with zip or gzip. In a traditional strategy pattern you'd have the Compressor class, a CompressionStrategy interface, and two more classes for zip and gzip strategies. You'd instantiate the zip method class and pass it into the Compressor class.

Instead, using lambdas, you can drop the interface and simply pass in the zip or gzip method as a parameter during Compressor construction.

The same argument applies to the command class.

Further, some SOLID principles, such as Liskov substitution become a non-issue under functional programming. "No inheritance, no problem!" This is gaining popularity in the modern OO community as: "compose, don't inherit."

The take away is that more languages are moving toward a hybrid approach, allowing the programmer to select the right tool for the job.

Exceptional Excerpts:

Notes:

Table of Contents

01: Lambdas: Parameterizing Code by Behavior
02: SOLID Principles
03: Design Patterns
04: Conclusions

01: Lambdas: Parameterizing Code by Behavior

02: SOLID Principles

page 15:

03: Design Patterns

page 31:

04: Conclusions











[About] [Contact]