What is wrong with Object Oriented Programming and what is right with Functional Programming?

I have been reading numerous articles about OOP and FP and comparison of these two recently. There are lots of differences and pro/cons for each of them but one important and interesting thing I recently found out was the fact that how tangled behavior and data are in OOP. I have been writing OO code for years, but I had not found out this until I read about FP and the way it handles data/behavior.

When you write a software in an OO approach, you must relate every behavior to a single isolated data entity (or class) in the business domain of the application. For example, when writing a code to send email, you have a data entity called “Email Message” and a behavior “Send a message”. There is no way for you to define these two separately. By separately I mean being able to invoke “Send Email Message” functionality without an “Email Message” object. Of course, you need a message when you want to send one, but this is a difference in the way we organize and approach things in OOP. When writing software in OO approach, you MUST define each behavior under one and exactly one class.

Question is, what if we cannot fit a behavior in this pattern? What if it doesn’t make sense or it is confusing to attach a behavior to one and only one class?

Considering above example about sending an email message, what happens if we have other entities in the application like Sender, Recipient, and Storage. Then where should I put “Send email message” functionality? Each one of the below candidates can be an acceptable place for putting this behavior.

  1. You can put “Send” method in “Message” class: msg1.Send();
  2. It can also be placed inside Recipient class: recipient.ReceiveMessage(msg1);
  3. It can also be part of Sender class: sender1.SendMessage(msg1);
  4. It can be part of a separate class. For example MessageBroker: MessageBroker.getInstace().SendMessage(msg1);

This is really confusing and IMHO unneeded complexity.

The advantage of Functional Programming approach is that you don’t have to bind each behavior to one class. They are completely separated. So you can define and use them separately. This type of modeling is more consistent with the way we think about software world concepts.

Of course for things which exist in the physical world, this is less of an issue (A car is the only object which can do the “Start” functionality). But for more abstract concepts which can only be found in the software world, I think FP approach makes more sense.

 

2 thoughts on “What is wrong with Object Oriented Programming and what is right with Functional Programming?”

  1. The problem I have with this article, speaking as a beginner, is that you talk about the abstract concepts only encountered in the software world and then don’t expand upon how your example could be expressed better in a functional style.

    Ignoring for a minute that recipient.ReceiveMessage(msg1) would be ann impossible way to model an email system, I can certainly see your point. You have to decide where behaviour goes and which bits of data it fits most snugly with. But if FP makes this easier, how would you model an email system in a functional language?

    In short, this post doesn’t really fulfil its title. It tells me what is wrong with OOP, or at least, one thing that’s wrong with it, even if it does so by using patterns of code structure that I hope aren’t used in the real world (even though I know they are). But this is the problem I have with FP. As someone who has learned an OOP style and knows no different, I’m surrounded by a sea of people telling me FP is better, who then completely lose my interest by failing to expand on their point, or doing so with a lengthy, mathematical and frankly boring discussion which will fly right over the head of someone who just wants their program to send an email.

Leave a Reply

Your email address will not be published. Required fields are marked *