Object Oriented vs. Functional Programming

A Little Background

After developing for over ten years in Java, PHP, and\or Rails, I was pretty comfortable with best practices for creating web applications. What I didn’t realize was that those best practices were for Object-Oriented web applications, not necessarily web applications per se.

When I tried to create my first web application in XQuery, I ran into all sorts of problems. I couldn’t figure out how to create table rows in a loop, or append values to a string, or do two statements in one call.

In hindsight, I have realized that what I was trying to do was use an OO approach in a functional programming language. There were fundamental differences between the two approaches, and not until I made the paradigm shift was I able to become proficient.

The phrase “paradigm shift” is used a lot in programming, and I suppose sometimes it is justified. But when I learned Rails and made a “paradigm shift” there, it was nothing compared to the real paradigm shift I had to make with XQuery. It actually helped me understand OO better, since I was able to contrast the two approached.

Object-Oriented Programming

In OO programming, everything is an object with two aspects: data and behavior. Objects have data (fields, members, attributes, etc.) which are either simple date types (int, String, boolean, etc.) or are objects themselves. You can get and set these values any time you can get a handle on the object, assuming the object implements a way for you to be able to do that (either directly or through accessor methods).

For example, an object in Java might look like this:

public class Person {
    private String name;

    public Person() {
    }

    public void setName(String name) {
        this.name = name;
    }

    public String getName() {
        return this.name;
    }
}

In this example, I can set the “name” attribute on a Person object whenever I want. Any other piece of code could, too. A particular instance of Person may or may not have a value for “name.” A particular instance of Person will remain in memory for as long as something keeps a reference to it, or until the application shuts down. I can have one part of my code pass a reference to this object to another part of my code. In fact, typically one part of code would set the “name,” pass the reference to of the object to another part of code which would then get the value of “name”  off of that object.

In OO programming, the entire system is basically a huge state machine, where objects are created and attributes set, and then the objects are passed around or referenced by other code. The application keeps track of all the object in memory and program execution passes from one object to another, setting data on objects along the way. And programmers are all too familiar with what happens when program execution is attempted on an object that doesn’t actually exist: the Null Pointer Exception.

Objects are a combination of both data and logic. You could decide to create an object solely to contain data (like a Data Access Object), or you could decide to create an object that has no data, ie. attributes (like a utility class), but they are still objects and you still must define a class for them and instantiate them.

All sorts of best practices have evolved around creating maintainable, stable, and performant applications based on the characteristics of OO programs. However, in functional programs, the characteristics are different. So not only are there different best practices, the best practices in OO may be worst practices in functional programming.

Functional Programming

There are no objects in functional programming that have attributes and behavior (at least not in XQuery). Data and code are totally separate. Functions control program execution, and while they can receive data in, they themselves do not have fields or attributes. Functions operate on data and pass the data around by value. Once a function passes some data to another function, that’s it. The sending function cannot keep a reference to the data; it passed the data. The receiving function cannot even modify the data. It can, however, create a new copy with modifications, and send that to another function or return it back to the calling function.

Some of the advantages of Functional Programming are:

1. Nothing can change your data. Once you get it, you’ve got your copy and it’s yours. Nothing can mysteriously change it while you are operating on it. Conversely, a function cannot affect data other than what it received (no side effect).
2. It’s threadsafe. There are no concurrency issues since nothing can have a reference to the same data. There’s no way for one function to interfere with the data in another function. And there’s no way for code to have stale references.
3. No Null Pointer Exceptions. NPEs happen when a piece of code knows the definition of an object (its class) but makes the mistake of trying to invoke methods on a non-existent instance of that class. In functional programming, there are no object instances of code. Function signatures are checked statically and then called, so there’s no chance of a code instance not existing, once those functions have been imported.
4. Expressions can be compounded. This one might take a little effort to grasp at first. Since there are no instances of objects, and since all data is always passed by value from one function to another, then you can have once function call another function and so on without having to worry about instantiating objects or checking for null values. I can pass a string value to substring function to a concatenation function to a parsing function to a date constructor to a date formatter, etc. So my code can be made of compound expressions that elegantly build the logic I need, rather than having to write a new function (or object or method) that does what I want it to do.

It’s well known in the Java world that stateless applications will perform better than stateful ones, everything else being equal. Enterprise Java Beans and web apps are often designed so that they do not need to maintain state information across requests if possible. In functional programming, there’s really no way to maintain state in memory (although you could write it to the database). Since there are no references to objects, there is a built-in performance advantage. Because of this, you can combine and compound several functions and still maintain high performance.

One thing that programmers new to functional programming have to keep in mind is that the only data you have to work with is that which is passed into the function, and the only way you can communicate anything from the function is in the return value. This forces you to think of exactly what your function should do since it can only return one result or sequence of results. You also cannot write functions that simply “do something” without returning a result. That would be violating the principle of “no side effects.” This is a mental shift that the programmer must make: from writing statements that do something, to writing expressions that return something. It might sound simple, but I think there are important fundamental differences in mindset and that’s what is necessary to make the paradigm shift.