Reference: Object Oriented Programming vs. Functional Programming by Bill Gathen

Object oriented programming as a programming paradigm has been around for a long time – since the late 1950s and early 1960s, with the term being introduced in the 1970s with the Smalltalk language. It is defined as:

Object-oriented programming (OOP) is a programming paradigm based on the concept of “objects”, which are data structures that contain data, in the form of fields, often known as attributes; and code, in the form of procedures, often known as methods.

Wikipedia

Functional programming as a programming paradigm has its roots in lambda calculus, with Lisp being an early functional-flavored language in the late 1950s, although it hasn’t received popular use until the last decade or so and can be seen in many languages not dedicated to this paradigm with frameworks such as React and Reactive Extensions (Rx). It is defined as:

Functional programming is a programming paradigm – a style of building the structure and elements of computer programs – that treats computation as the evaluation of the mathematical functions and avoid changing-state and mutable data.

Wikipedia

Both paradigms have the shared goal of creating understandable, flexible programs that are free of bugs, but they have two different approaches for how to best create those programs.

In an article posted in 2014 on this subject, Uncle Bob boils these two paradigms down to this:

• FP imposes discipline upon assignment. Immutability provides safety, particularly in multiprocessing and multiprocessor environments.
• OOP imposes discipline on function pointers. Polymorphism allows stable high-value business rules to be kept from depending upon volatile low-value modules such as user interfaces and databases.

OOP and FP each have their appropriate use cases. Neither is a panacea.

Richard Warburton’s eBook Object-Oriented vs. Functional Programming: Bridging the Divide Between Opposing Paradigms attempts to compare the two paradigms, primarily using the SOLID principles as a means of comparison. Based on my review of his eBook, I walked away with the following points:

• FP avoids or can easily satisfy all the SOLID principles.
• FP and OOP can coexist in the same codebase.

From When FP? AND when OOP? on ragenwald.com:

The biggest difference between the two “schools of thought” concerns the relationship between data and operations on the data.

The central tenet of OOP is that data and the operations upon it are tightly coupled: An object owns its data and it owns the implementation of the operations on the data. It hides those from other objects via its interface, a collection of methods or messages it responds to. Thus, the central model for abstraction is the data itself, hidden as it is behind a small API in the form of its interface.

The central activity in OOP is composing new objects and extending existing objects by adding new methods to them.

The central tenet of FP is that data is only loosely coupled to functions. You can write different operations on the same data structure, and the central model for abstraction is the function, not the data structure. Functions hide their implementation, and the language’s abstractions speak to functions and the way they are combined or expressed, such as generic functions or combinators.

The central activity in FP is writing new functions.

I like the final statement made by this article:

Good software is written in both styles, because good software has more than one need to satisfy.