At its very core, software development is the skill of taking a complex problem and breaking it down repeatedly until it contains many simple problems.
When explaining the difference between OOP and FP, I often resort to a (massively oversimplified) approach in how both of these approaches break down a complex problem into its constituent parts, but they use a different order of operations.
A customer wants to purchase a product. They contact a vendor, ask for a pricing, buy the product and then the vendor ships the order.
An OOP developer breaks it down like this:
Customer wants to purchase a
Product. They contact a
Vendor, ask for a
Pricing, buy the
Productand then the
Vendor ships the
In short, an OOP developer first defines "things that exist" (objects/entities/...), and will at a later stage write the behaviors (interactions between objects).
But an FP developer breaks it down like this:
A customer wants to
buyProduct and then the vendor
In short, a FP developer first defines "things that can be done" (features/functions/actions), and will at a later stage write the necessary data (objects/entities/...) that are needed to chain these actions together.
In both approaches, you will eventually have developed both the actions (purchasing, contacting, ...) and the data (customers, products, ...), but you first defined one before you defined the other. OOP developers start with the data, FP developers start with the actions.
Question: What thought process would lead to the invention of object-oriented programming?
Initially, software development following a scientific context, where it was used mostly to assist scientist in calculating values with better performance and accuracy. At this point, functional programming reigned supreme, as mathematics are inherently defined as a set of functions/operations.
When someone was asked to develop an algorithm, the purpose of the algorithm was explained to them by a physicist/mathematician, and therefore the instructions already following a functional pattern.
However, at some point software started being used in a non-scientific context, for data in/output. In this world, there is a tendency to take a more OOP-like approach by first defining the data records that are expected to contain the data.
When someone was asked to develop software for this, they received instruction in an object-like format.
Having to translate the object-like specifications to functional language wasn't easy, but it could be made significantly easier by having the language mirror the specifications (as it reduces the need for complex translations). This is where OOP languages started emerging, which specifically defined the data points before any interactions between them would be discussed.