Object-Oriented Programming vs Functional Programming: The Battle of the Languages
With the ever growing number of computer languages available to programmers, it can get a little overwhelming when it comes to choosing one to learn. Maybe you have a friend who swears that Python is the best, or you read a blog who’s author claimed that JavaScript is actually the best. Maybe you just decided you wanted to learn Ruby because you thought it had a cool name? For whatever reason you might choose a new language, it’s vitally important you understand how that language works and what problem(s) it is best suited to solve. Thus begins the battle of Object-Oriented Programming (OOP) vs Functional Programming (FP).
In order to understand the difference between OOP and FP, and eventually deciding which one you want to use, it’s important to understand how each of them work:
“In the blue corner…”
We have Object-Oriented Programming! Created in 1958, the first language recognized as “OOP” was Simula in 1965. It was later adopted and popularized by C++ and Java in the 80’s and 90's, Object-Oriented Programming (OOP) comes primed and ready to beat your code into submission with languages such as Python, Swift, Ruby, C++, C#, Java, and many more. Relying on its “stateful” programming model, OOP relies on encapsulating — or, hiding variables within the class from outside access — to keep your code safe from those pesky unwanted external usage. Methods become access points to the state and process the instance of the object as need be, hence, “object” oriented. Using the power of the “mutable object” to manipulate your methods, OOP is ready to perform a TKO on all of your coding needs.
“In the red corner…”
We have Functional Programming! Ready to fight on behalf of all of your fixed data, Functional Programming (FP) eliminates all of your unwanted side-effects by relying on functions to program around your “immutable objects.” Believing that if x + y = z, your program should always return z if x and y remain constant. Including languages such as Python(again), Haskell, and JavaScript, FP is the defender of all your functional needs, with little risk of unwanted bugs.
Programmers, let’s get ready to RUMBLEEEEEEEEE…
… and after a solid 12 rounds, the winner goes to…
“Wait, what do you mean it’s a draw?”
After a highly contested battle, the judges have decided that both types of programming paradigms are perfectly valid and both have their proper time and places.
“Let’s analyze the judge’s scores.”
While one will thrive and work better for the project based on environment and requirements, neither solution works best in all situations:
Functional Programming works well in simpler solutions. It thrives in front-end situations because back-ends are giving objects for front-ends to process. The client doesn’t care about maintaining object states because it’s already given to them. Recently, functional programming had a surge in popularity through React. The library works well under the functional programming paradigm because it provides an environment where you’re not required to manually track states.
Object-Oriented Programming works well in the back-end because most of the time, you’re required to construct something to give to the next boundary. Data is stored in objects since the data and respective behaviors (meaning, what a program can do to, or with, data) should belong to a single location. It needs to be packaged up and wrapped in a ribbon before posting it away into the unknown.
So there you have it, at the end of the day, one is not inherently better than the other. Each method has the end goal of creating clean and efficient code and the two together have the power and ability to solve all programming needs. This is why I will always be doing my best to use a hybrid of the two.
