While Dart is in its core an object-oriented programming language, that doesn’t mean that you’re stuck only with that paradigm. In fact, Dart is something called a multi-paradigm language! Functional programming (FP) makes your code easier to test and reuse, and also makes it less error prone.

With Dart, it’s easy to start introducing practical functional concepts into your code in a reasonable amount. This way, you reap the benefits of FP while not confusing others (and yourself) with how your Dart code is written.

Imperative vs Functional Programming

Before we can start looking into any of the more advanced concepts of FP, let's get the basics out of the way so that we're all on the same page. Let's look at a very simple example where we want to sum the numbers inside a List<int>. First up, the imperative approach:

These are absolutely simple few lines of code where we sum the integers inside of the List using a for loop.

In order to accomplish this though, we need to create a mutable int sum, then another int i that we don't even really care about, it's just there so that the for-loop can run. Inside of the loop, we mutate the sum variable by adding to it the integer value present in the list at the index we're currently iterating over.

This is all simple, of course, but we're really managing the workings of our program by ourselves and telling it what to do step by step. Should this bit of code do something more complex than just summing a list of integers, we could have trouble reading and maintaining it.

Let's now look at how we can do the exact same thing in FP:

Instead of creating a for-loop, we call fold on the list. We can declare the sum variable to be final. It is no longer mutable thus making the code less error prone from us accidentally mutating this variable from another place in the codebase.

We also don't need to worry about managing a for-loop using some sort of an iterative variable. The fold method operates on a higher level of abstraction and just provides us with the previous sum and the current element value that we can add to the previous sum. No need to worry about indexes or any other implementation details. 

Overall, the functional approach has less moving parts and is less error-prone.

More Complex Example

In another just a little bit more complex code, we have a List<String> from which we want to create a new List that holds both the original String and also its length inside of a record (String, int). Imperative code looks like the following:

If we now decide that the charCounts list should only contain strings that are longer than two characters, we need to write an if-statement inside of the for-loop.

We again need to get into the already existing code, find out its implementation details (e.g. that the iteration variable is int i ) and only then can we add this new functionality.

If we implement the exact same thing in a functional approach (at first without filtering the strings by length), we get:

The code is looking much cleaner without the for-loop already. However, the functional approach really shines once we try to filter the strings by length.

We don't need to get inside a previously written code and study its implementation details before we add the new functionality. All we need to do is to chain method calls that are separate from each other, yet can work together as well to create a brand new functionality.

It's something like pieces of Lego that look good separately but you can also join them in various ways. If we were to fit the imperative approach with the for-loop and an if-statement into this Lego analogy, it's as if we were not simply joining individual pieces together, but rather cutting things out with a scalpel and then melting these odd cut-up pieces together with a blowtorch (not so nice).

OOP vs FP Class Hierarchies

Dart is a strongly object-oriented programming language where everything is a class. Even all the functions you write are in the end understood as classes with a method, more specifically, subclasses of the Function abstract class from the dart:core library.

This, however, doesn't mean that you are stuck with only the OOP paradigm! Dart has all the features needed to support a FP approach to class hierarchies by allowing you to create algebraic data types.

First, let's take a look at a regular class hierarchy. All of the following code has been taken from an official Dart article on Medium but I've modified the pseudocode to actually be able to compile and run.

The abstract base class Recipe has three fields and a single method. All of the subclassed Cake and Cookies then assign their own values for these fields and implement the bake method.

This is a standard example of a class hierarchy in OOP but let's now write the exact same thing with an FP approach.

Notice that the class Recipe is no longer marked abstract but rather sealed. All the fields remain the same and the Cake and Cookies subclasses populate those fields with their own values through the super-constructor just as in the OOP approach but notice what's missing. There is no bake method in any of the classes. Instead, it's now a top-level function.

Algebraic data types separate data from logic. The code run by the bake function is exactly the same now as it was when it was a member method inside of the classes but now we're using a switch statement to execute the proper code for any Recipe subclass that was passed in.

Because the Recipe base class is sealed, the switch statement will not compile unless we switch through all the existing subclasses of Recipe, so the FP code is just as safe to write as the OOP version.

Pure Functions

Separating data from the operation performed with that data resulted in having a top-level bake function which is only dependent on its parameters and can "communicate with the outside" only by returning a value. Here it returns void but the point still stands. This makes bake a pure function.

With the OOP approach, the bake function was a member of a class (a method), and accessed the fields of the class. Although in our case this didn't happen, such a method can also mutate fields of the class, thus making the return value not the only point of communication with the outside.

The advantages of a pure function as opposed to an unpure method are that it's easier to test and maintain since EVERYTHING a function does is contained within it. There are no possible side effects somewhere else in the codebase and you, for example, can't forget to mock an object while testing because every dependency of that function is passed in as an argument.

Error Handling

Another area where FP principles shine is error handling. Enough of those exceptions and try-catch statements all over the place! While we could write all the functional error handling code from scratch, we're going to use the fpdart package which is a must-have in your project if you want to move more into the FP paradigm.

Let's say we have the following enum implementation for a US-style grade that can be A, B, C, D or F and we also have a method for parsing strings. If the string contains something else that a valid grade letter character, we throw an ArgumentError.

The problem with throwing errors like this is that the following will compile without an issue.

You see that? We're missing a try-catch block but we're going to find about this only at runtime when our app crashes because of an uncaught ArgumentError.

It's easy enough to remember to wrap the grade parsing with a try-catch in this small example code but in complex apps its incredibly hard, if not impossible, to remember which method throws which kind of an exception and to catch everything properly.

Sure, you can write documentation and comments all over the place but still, you're relying on yourself to remember things. It would be much better to let the Dart compiler let you know that you're not handling errors correctly. Failing at compile time is what we want, not at run time.

Using Either

The fpdart package provides us with a type called Either. In its principle it is a generic sealed class with two subclasses - Left and Right. The left "side" of Either holds the error while the right side holds the right (correct) value.

The principle of using Either is to unify the exception flow and data flow into the return type of a function. In our simple case, the left side will hold only the error message string.

Since we've eliminated the separate flow of exceptions the following code will not compile.

We're now forced to handle the error and that's a good thing! Either is just a regular sealed class so we can technically use the regular switch statement...

But the convention is to use the helper match method on the Either class to do the same thing in less lines of code.

Conclusion

In this tutorial you've learned the basics of practical functional programming principles and also error handling using the Either type. Understanding these foundations allows you to venture further into functional programming with the fpdart package. I will cover some of the more advanced techniques of writing FP code in an upcoming tutorial so make sure you're subscribed not to miss it!