Functional Programming vs Object Oriented Programming — Why You Don’t Need to Choose Anymore? | by Ivelina Yordanova | Apr, 2022

A high-level overview of the essential ideas in each and how one can mix them successfully

Photograph by Brendan Church on Unsplash

In case you come from a standard laptop science training, chances are high you will have began studying to program utilizing an crucial fashion i.e. “telling” the pc precisely what to do and in what order.

That is often the place to begin, irrespective of the precise language of alternative as a result of it’s intuitive and eases you into coding whereas studying a sea of different ideas and theories. In distinction, purposeful programming doesn’t come as straightforward, particularly in case you have began with OOP (object-oriented programming).

Looking on-line you’ll discover these two methodologies pitted towards one another as if it is advisable make the selection as soon as and reside with it endlessly.

Software program engineers are inclined to go together with daring statements like “it’s all or nothing”, “my facet or the improper facet”. You’ll discover folks on both facet which are very adamant about following the “pure model” of the chosen one and so they’ll have good arguments.

I, for as soon as, am not that excessive. I take pleasure in fixing issues in essentially the most environment friendly and clear method and which means having your eyes open for instruments, frameworks, languages, and on this case ideas you possibly can combine to attain the duty at hand.

I favor maintainability and readability over conciseness. Having folks obsess in regards to the brevity of their code is shedding monitor of the primary objective generally. It’s positive in case you the entire firm or no less than the crew are decided to maneuver to pure purposeful programming but when it’s only some builders right here and there then that creates a information hole and leaves the code weak — if anybody from the remainder of the crew must make adjustments it’s twice as more likely to introduce a bug(if not examined correctly) or no less than take twice as a lot time. What occurs when these folks depart the corporate… in all probability money and time spent on rewriting.

The place I’m going with that is, that there’s extra to think about when making the choice to leap into both and also you don’t should. I feel there’s a superbly wholesome and fairly well-behaving center.

Earlier than we’re capable of pull issues into the center, we’d like to ensure we’re conscious of what essentially the most fundamental ideas in every are.

1. Abstraction

Abstraction refers back to the thought of hiding the main points of the precise implementation and solely exposing a clear and easy-to-use interface through the strategies within the class. The primary good thing about a well-abstracted class is that adjustments to the code stay clear to the caller.

2. Inheritance

Courses may be organized into hierarchies, the place a toddler class routinely obtains plenty of the identical performance and properties from the mother or father one and might override or increase on that performance and information. It permits for code reuse immediately by means of the hierarchy or by defining capabilities working with it.

3. Polymorphism

Polymorphism permits defining totally different implementations of a perform with the identical identify. This may be achieved both by means of overloading — having strategies with the identical identify however totally different arguments, or overriding — offering class-specific implementation of a way current with the identical identify in a mother or father class.

4. Encapsulation

In OOP, the info and capabilities which function on it must be certain right into a single unit, a category. This enables some particulars to stay personal and solely to reveal the performance that’s essential for interfacing with it. A well-encapsulated class doesn’t enable entry to its personal information immediately.

1. Excessive Order Features (HOF)

In FP capabilities are first-class residents, they are often assigned to variables, handed as arguments, and saved. Features that settle for different capabilities as arguments are known as HOF. Usually, particularly when writing HOFs, we would need to make our code extra generic — to permit it to simply accept any kind. These are known as polymorphic capabilities.

2. Pure perform

Practical applications work with immutable information i.e they don’t replace variables or modify mutable information constructions. They function with pure capabilities, which is one that doesn’t carry out any uncomfortable side effects.

So, what precisely qualifies as a facet impact?

  • Modifying a variable past the present scope
  • Modifying an information construction in place 
  • Setting a subject on an object 
  • Throwing an exception
  • IO operation

3. Recursion

In FP loops are represented as recursive capabilities.

There’s a particular subcategory right here — tail recursion, which is when the recursive calls made by a perform are in tail place.

In Kotlin, if that’s the case and the perform is outlined as tailrec , then the recursion is compiled to iterative loops that don’t devour name stack frames for every iteration and also you’ll get compile-time checks with that.

To ensure that a perform to be tailrec, the recursive name within the caller ought to do nothing aside from return the worth of the recursive name. For instance, on this Fibonacci implementation the perform solely returns itself.

tailrec enjoyable fibonacci(n: Int, a: Int = 0, b: Int = 1): Int = 
when (n)
0 -> a
1 -> b
else -> fibonacci(n — 1, b, a + b)

If we had been producing another odd sequence with a name like

enjoyable myRandomSequence(n: Int, a: Int = 0, b: Int = 1): Int = 
when (n)
0 -> a
1 -> b
else -> myRandomSequence(n — 1, b, a + b) + 9299

The compiler wouldn’t be capable to rework this to an iterative loop since we have to go all the way in which down within the stack to get the underside worth and add the 9299 to it after which go all the way in which again.

4. Strict and Non-strict Analysis

Most fashionable programming languages use strict analysis by default. That’s, expressions are evaluated in the intervening time they’re certain to a variable.

This consists of when they’re handed to capabilities as parameters. In distinction, non-strictness as a property of a perform means it might not consider a number of of its arguments.

This may increasingly sound odd at first however we’re already conversant in the idea of not evaluating a part of the code.

if (x == true || y == false)  
// doA()
else if (w == true && z == true)
// doB()
// doC()

Within the above instance, there are 3 language constructs that forestall bits of code from evaluating. The boolean operators solely consider the primary bit — for or if the situation is met and for and if it’s not. Equally, if the situation within the if part is evaluated to true, doA can be executed and the second situation, in addition to the opposite doX actions, can be skipped.

Kotlin doesn’t present a solution to mark a perform as non-strict or an argument as non-evaluated, however there’s a solution to specific that idea in a extra express method.

enjoyable nonStrictIf(situation: Boolean, onTrue: () -> Unit, onFalse: () -> Unit) = if (cond) onTrue() else onFalse()val y = nonStrictIf(x==true,  println(“x is true”) ,  println(“x is fake”)  )

5. Referential Transparency (RT)

An expression is referentially clear if all of its occurrences may be changed by the results of its analysis with out affecting the results of this system. Going again to the definition of a pure perform, it has to additionally meet this definition and be referentially clear for all referentially clear arguments.

In very broad strokes that is the distinction between the 2 methodologies:

For me, although, they shouldn’t be introduced as mutually-exclusive options, however as are orthogonal, complimentary ideologies. OOP is all about modeling the world, whereas the FP is about processing the info and so they may very well be mixed naturally.

FP rejects the concept of state whereas it’s unavoidable in the actual world and sophisticated functions can profit from utilizing each approaches. Essentially the most intuitive and customary method of doing that’s “purposeful within the small, object-oriented within the giant” . Primarily, this implies utilizing OOP ideas to design the applying and mannequin your entities however implementing the logic at technique degree inside these utilizing the FP paradigm.

Apart from mutability and uncomfortable side effects not one of the different concepts in FP are that controversial or wild coming from OOP. What’s extra even past consciously attempting to implement a particular combined mannequin, I feel it’s at all times a good suggestion to intention for immutability and solely use mutable objects and variables when completely essential and unavoidable.

Avoiding uncomfortable side effects can also be a very good apply it doesn’t matter what, for the sake of higher testability and with that avoiding bugs. Your strategies in OOP must also do solely and precisely what the identify suggests, it’s not one of many core ideas nevertheless it’s one of many good design practices anyway.

What’s extra? Numerous the languages usually labeled as OOP are usually not solely and purely OOP — Kotlin, Scala, and even Java now slowly including bits and items from FP. So, now it’s not about OOP vs FP, it’s about utilizing them in conjunction to attain essentially the most environment friendly, strong, clear utility.

Thanks for studying!

More Posts