OOP revolves around the concept of "objects" which have attributes in order to put together a complex computer program, as opposed to procedurally giving the computer direct instructions.
FP is designed around more mathematical-style computations on values.
OOP:
thing.doSomething
Functional:
doSomething(thing)
There are fairly strictly functional, and object oriented programming languages, and then there are plenty that nibble at each style without providing strictness.
They each have their place and their specialties, but they can also be used to solve similar problems in different ways. They each make some things easier and some things harder. OOP is definitely more "mainstream".
Hello! My name is Thomas and I'm a nerd. I like tech and gadgets and speculative fiction, and playing around with programming. It's not my day job, but I'm working on making it a side gig :)
There's way more to the differences between OOP and FP than how you call functions/methods, and when you boil it all down it's really all to do with how your code and data is organized.
If we ignore the fact that most languages misunderstand the original idea of object orientation, OOP tries very hard to bundle code and data together in separated units so that all the code that has to do with some data is passed around with that data.
When you create an object of that type you get all the methods you need to work with that object bundled alongside it, but you also get all the methods you aren't going to use, and if you need to do something that the object doesn't already know how to do then you get into the territory of subclassing or extending/monkeypatching that object.
In Functional Programming, there is a bigger separation of code and data (unless you're using a LISP, but let's not complicate matters). You have some data that you can pass around in your program, and then you have some code (functions) that operate on some data. The code is not tied to some particular data, it is independent. If we look at a language like Python for example you have the function len(). It's not coupled to any object (despite Python being heavily OOP), instead you can call len() on literally anything and for nearly every piece of data you throw at it len() will respond with a length/size that is appropriate for the type of data you provided it with.
This comment on StackOverflow illustrates when it would be a good thing to choose one over another, and why multi-paradigm languages (Python, Nim, JavaScript) are generally more ergonomic than single-paradigm languages are since they let you freely choose whichever style fits the current problem instead of trying to shoehorn your solution into whatever paradigm. That's where all the problems come from where you invent convoluted patterns for OOP to solve issues that are trivially solved if you weren't forced to make everything a class (C#, Java), or where you get into hairy mathematical concepts like Monads to circumvent your language not wanting you do make functions with side-effects such as printing some text to the console (Haskell).
Programming languages and software in general exist to solve problems, they should get out of your way and help you to make things easier. Not force you to tricks and hacks.
PS.
If you look at a language like Nim you'll see why it's not useful to look at how things are called to determine the differences in paradigms:
typeVector=tuple[x,y:int]proc add(a,b:Vector):Vector=(a.x+b.x,a.y+b.y)letv1=(x:-1,y:4)v2=(x:5,y:-2)echoadd(v1,v2)# "functional" styleechov1.add(v2)# OOP styleechov1.addv2# Don't even need parenthesis if it's unambiguous
Coding consists of two major parts, one logic and one is organizing logic. Consider logic as a contents of book and organizing as a book library.Book Library is organized by categories and then it is further organized by either author name or title in dictionary form. Imagine if you had a good contents of book but if it wasn't organized properly. Imagine if everyone organize contents of book and book in library with random order.
I consider class as a way to organize logic, you still have your functional ways to write logic but class is well understood by everyone and it is easy to document and organize. And it is very easy to refactor the code because IDE knows all references of identifier and it can safely refactor it. This was basically the reason why C++, Java and C# became more popular because developers need not focus on how to write it correctly and were able to focus on business needs.
Ideally doing everything in OOP or everything in Functions, both are bad, you must choose OOP to organize your logic, which is extremely important for long term healthy library and functions to improve your logic.
Imagine three people sitting in a room, lets call them Anna, Brad and Carol.
In object oriented programming, Anna has a paper with cats written on it, and Brad has a paper with are cool written on it. Then Carol comes and asks Brad what do you think?. Brad asks Anna what do you have?, Anna looks at her paper and answers cats. Brad then looks at his paper and answers to Carol Cats are cool.
In functional programming, Carol comes and asks What do you think? then Anna produces a piece of paper, writes cats on it and passes it to Brad. Brad looks at the paper and writes are cool next to cats. Then they hand out the paper to Carol and she reads cats are cool.
It's worth reading the replies I got because we discussed about immutability also, which my original comment doesn't address.
Top comments (9)
Different paradigms for making a program work.
OOP revolves around the concept of "objects" which have attributes in order to put together a complex computer program, as opposed to procedurally giving the computer direct instructions.
FP is designed around more mathematical-style computations on values.
OOP:
Functional:
There are fairly strictly functional, and object oriented programming languages, and then there are plenty that nibble at each style without providing strictness.
They each have their place and their specialties, but they can also be used to solve similar problems in different ways. They each make some things easier and some things harder. OOP is definitely more "mainstream".
There's way more to the differences between OOP and FP than how you call functions/methods, and when you boil it all down it's really all to do with how your code and data is organized.
If we ignore the fact that most languages misunderstand the original idea of object orientation, OOP tries very hard to bundle code and data together in separated units so that all the code that has to do with some data is passed around with that data.
When you create an object of that type you get all the methods you need to work with that object bundled alongside it, but you also get all the methods you aren't going to use, and if you need to do something that the object doesn't already know how to do then you get into the territory of subclassing or extending/monkeypatching that object.
In Functional Programming, there is a bigger separation of code and data (unless you're using a LISP, but let's not complicate matters). You have some data that you can pass around in your program, and then you have some code (functions) that operate on some data. The code is not tied to some particular data, it is independent. If we look at a language like Python for example you have the function
len()
. It's not coupled to any object (despite Python being heavily OOP), instead you can calllen()
on literally anything and for nearly every piece of data you throw at itlen()
will respond with a length/size that is appropriate for the type of data you provided it with.This comment on StackOverflow illustrates when it would be a good thing to choose one over another, and why multi-paradigm languages (Python, Nim, JavaScript) are generally more ergonomic than single-paradigm languages are since they let you freely choose whichever style fits the current problem instead of trying to shoehorn your solution into whatever paradigm. That's where all the problems come from where you invent convoluted patterns for OOP to solve issues that are trivially solved if you weren't forced to make everything a class (C#, Java), or where you get into hairy mathematical concepts like Monads to circumvent your language not wanting you do make functions with side-effects such as printing some text to the console (Haskell).
Programming languages and software in general exist to solve problems, they should get out of your way and help you to make things easier. Not force you to tricks and hacks.
PS.
If you look at a language like Nim you'll see why it's not useful to look at how things are called to determine the differences in paradigms:
Good explanation! Note that since Java 8, you got Lamdas. So you don’t need to make everything a class, but you can pass in functions as parameters
Yup I see
OOP is widely used in production since JAVA dominated the industry in the late 90's
Exactly.
This is exact same comment on different article by me, dev.to/akashkava/comment/7fig
Coding consists of two major parts, one logic and one is organizing logic. Consider logic as a contents of book and organizing as a book library.Book Library is organized by categories and then it is further organized by either author name or title in dictionary form. Imagine if you had a good contents of book but if it wasn't organized properly. Imagine if everyone organize contents of book and book in library with random order.
I consider class as a way to organize logic, you still have your functional ways to write logic but class is well understood by everyone and it is easy to document and organize. And it is very easy to refactor the code because IDE knows all references of identifier and it can safely refactor it. This was basically the reason why C++, Java and C# became more popular because developers need not focus on how to write it correctly and were able to focus on business needs.
Ideally doing everything in OOP or everything in Functions, both are bad, you must choose OOP to organize your logic, which is extremely important for long term healthy library and functions to improve your logic.
Well crafted answer
And it explains really well
Thank you
I recently wrote a reply to a very similar post.
Imagine three people sitting in a room, lets call them Anna, Brad and Carol.
In object oriented programming, Anna has a paper with cats written on it, and Brad has a paper with are cool written on it. Then Carol comes and asks Brad what do you think?. Brad asks Anna what do you have?, Anna looks at her paper and answers cats. Brad then looks at his paper and answers to Carol Cats are cool.
In functional programming, Carol comes and asks What do you think? then Anna produces a piece of paper, writes cats on it and passes it to Brad. Brad looks at the paper and writes are cool next to cats. Then they hand out the paper to Carol and she reads cats are cool.
It's worth reading the replies I got because we discussed about immutability also, which my original comment doesn't address.
Functional:
OOP: