The Syntactic Benefit of Object Orientation
Some people say you should use Functional Programming (FP) instead of Object Oriented Programming (OOP). I assume there are also people who say you should use OOP instead of FP, although I haven’t really heard that.
In this article I argue that FP vs. OOP is a false dichotomy but that there is one aspect where the choice between them matters.
FP vs. OOP False Dichotomy
There’s no reason you couldn’t or shouldn’t use both in the same program, most of the time. Methods of objects are functions which can be “first class citizens”. Objects can be immutable. And functions can have methods.
A good example of a language that supports both is JavaScript/ES6, where you can “freeze” objects to make them immutable, and it’s easy to attach function-valued properties to functions, in other words functions are objects which can have methods too.
The following picture shows how deeply intertwined Objects and Functions are in JavaScript. Each statement below is true:
There is one situation where you have to make a choice between OOP and FP, and where OOP is clearly better. But first let’s discuss what is Object-Orientation , so we know what we’re talking about.
What is Object Orientation?
The simplest and most basic description of Object Orientation I can come up with is this:
A function associated with an object (known as “method”) can be called in such a way that the object the function is associated with becomes an implicit argument of that function-call.
That’s a mouthful but I don’t think I could make it any shorter. That is the basic principle of Object Orientation. Let it sink in. What makes Object Orientation Object Orientation: the ‘this’ inside methods.
That special implicit argument in some OO languages is called ‘this’, in some it is called ‘self’. It refers to the object that “owns” the method-function, the object it is associated with, the object it is “called upon”. The ‘this’ contains the explicit context in which the function is executed, meaning it carries the other properties and methods of the owner-object when the method is executed.
Why does this matter? It matters because it makes programs more understandable, more readable when the syntax lets you express who is the “owner” of the function separate from its name, in context.
It’s like when you talk to Bob, Bob knows you are talking to him. There may be other Bobs in the room but they see you are not addressing them directly, so they won’t try to answer. Object Orientation brings that same principle of “talking TO somebody” to software.
The Syntactic Advantage of Object Orientation
Imagine you have a method that takes an Array and a Function as arguments and applies the function to every element of the array. You may know this function is commonly called ‘map()’.
You could call it like this:
map (myArray, myFunction)
That is the Functional Programming Syntax. You call the function map() passing in its arguments inside the parenthesis, explicitly. That works fine if there can only be one “map”. But never say never.
The Object Oriented Syntax for calling map() is:
myArray . map (myFunction)
So what’s the big deal? Both expressions take the same number of characters to read and write. Should I prefer the Object Oriented Syntax or Functional Programming Syntax? Which one makes my program easier to understand?
The answer is: The OO Syntax is better. For two reasons:
- It makes it clear which Bob you are taking to, where the implementation of the function ‘map’ comes from. Different objects can have their own separate function ‘map’ which gets executed based on which object you ask. It is clear from the manner of your expression (= syntax) which object’s “map()” will get executed .
- You don’t need to ask “Are the arguments in correct order?”. There is now only one (explicit) argument to the Object Oriented method “map()”. So that question is moot. You can’t call it with wrong order of arguments.
So even though OO vs. FP is a false dichotomy there is one circumstance where it matters: The syntax you use. The object-oriented “method-owner . method-name” -syntax gets increasingly advantageous as your program grows, as your company starts employing more than one Bob.
The OOP syntax means the same code can be reused to “talk to” different types of objects to produce different results. Different Bobs do their “own thing” in their own way.
There’s a difference between talking ABOUT (some, whom?) Bob and talking TO (some specific) Bob. If you just talk about Bob you’re not making it clear which Bob. If you need to get a specific Bob to do something you better talk TO him directly.
Object Oriented Syntax allows you to do that, make it clear which section of your code should provide the implementation for executing a given call. That makes your programs easier to understand.
LINK: