Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Functional Programming Provides Safety Restrictions on Object Orientation

DZone's Guide to

Functional Programming Provides Safety Restrictions on Object Orientation

Learn more about the difference in limitations between functional programming and object orientation.

· Java Zone ·
Free Resource

Secure your Java app or API service quickly and easily with Okta's user authentication and authorization libraries. Developer accounts are free forever. Try Okta Instead.

To see a very simplistic relationship between imperative, OO and functional programming, we need to look at memory structures used within computers and programming languages. The following table goes from least restrictive to most restrictive. It also demonstrates how each level further restricts the previous level.

Memory Level

Restriction on previous level

Description

Hardware

The physical RAM, CPU caches, swap space, etc.

Process Space

Addressable finite amount of memory for process

The operating system provides memory address abstractions that allow a process to reference its available memory.

Buffers

Process memory is requested from the operating system as a buffer. This allows direct bit manipulation of memory.

The addressable space is much larger than the available RAM/swap space/etc. of the computer. Hence, the operating system allocates the memory only on demand/request. Typical programming at this level is for HTTP network communication, screen displays, and other low level functionality.

Structs

A Struct can be thought of as a buffer that organizes the bits into higher-level fields (e.g. integers, bytes, longs, floats, chars, address references, etc.)

Structs enable imperative programming to pass by reference.

Classes

Makes the Struct fields private by default, with methods controlling accessing/mutating the fields

Classes are the foundation of object-oriented programming.

Immutable Objects

Disallows mutating the fields.

Immutable objects are the foundation of pure functional programming.


So, from a memory point of view, functional programming can be considered more restrictive programming than imperative/object-oriented programming (and buffer, operating-system programming before that).

This restriction of what the developer can do allows more prediction by the compiler to optimize code.  It also allows your code to be safer, as reduces race conditions and various other issues coming up from typical Object Orientation of mutating fields.

However, just because your functional language has this purity to make your code safer. There are times when developers need the flexibility to code at lower memory restriction layers. Some problems, for just performance reasons, even require you to code at the buffer level (just see TechEmpower Benchmarks regarding some of the fastest web servers). Yes, the purity is useful for cleaner, more abstract application code, but it should not be your only proverbial tool in the language's belt.

So, why let compilers and functional frameworks (such as Spring Reactive) be afforded these restrictions of what you the developer can do?  In particular, why can't we have transactions that Reactive frameworks disallows?

Stay tuned for our next article where we will look at functional frameworks and introduce dependency contexts to avoid these restrictions.

Secure your Java app or API service quickly and easily with Okta's user authentication and authorization libraries. Developer accounts are free forever. Try Okta Instead.

Topics:
inversion of control ,dependency injection ,thread pools ,function composition ,functional programming ,object orientation ,java

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}