Tag Archives: Functional Programming

Functional Domain Programming Cookbook

Posted on by

In this article, I will demonstrate how Typed Functional Programming can be used to effectively represent a domain. We will walk through a step-by-step example where different domains are modeled using types and subtypes, and functions are used to transform one domain into another.

Let’s consider the process of making a cake as described in a recipe. The first step is the list of ingredients.

sealed trait Ingredient
case object Flour extends Ingredient
case object BakingPowder extends Ingredient
case object Water extends Ingredient


This list is defined in the recipe, but we cannot be certain that we have all these ingredients in our kitchen. To express this uncertainty, we create another type:

sealed trait NeededIngredient {
  val ingredient: Ingredient
}
case class MissingIngredient(ingredient: Ingredient)
  extends NeededIngredient
case class PresentIngredient(ingredient: Ingredient)
  extends Ingredient


With these types, we can define the first operation needed to start the cake:

def getIngredients(ingredients: Ingredient*): List[NeededIngredient]


The result is a list of NeededIngredient, which can be either present or missing. While we could have used the standard library’s Option type, it wouldn’t offer the same level of expressivity. In this case, we explicitly want to know which ingredient is missing; a None would have hidden that information.

The next part of the recipe involves mixing those ingredients.

def checkAndMix(ingredients: List[NeededIngredient]):
  Either[MissingIngredients, Mixture]


The checkAndMix function results in either a successful mixture or a collection of missing ingredients.

case class Mixture(ingredients: List[Ingredient])
case class MissingIngredients(ingredients: List[Ingredient])


We could have represented this result differently. Instead of Either, we could have created a custom sealed trait:

sealed trait MixtureResult
case class FullMixture(ingredients: List[Ingredient])
  extends MixtureResult
case class PartialMixture(present: List[Ingredient],
                          missing: List[Ingredient])
  extends MixtureResult


While this looks elegant, it is actually invalid for our domain: if you don’t have all the ingredients for a cake, you don’t start mixing – that would be a waste!

Either is the correct solution here because it represents a domain disjunction. This means two completely different domains have only one thing in common: they are both valid results of the function, but they cannot exist at the same time.

The final step is baking the mixture.

def bake(mixture: Mixture): Cake


This function only takes a Mixture as input, which is the correct definition from a domain perspective. We want to express that we can only bake after we have successfully mixed the ingredients. The Either type is perfect for this via a map operation:

val neededIngredients = getIngredients(Flour, Water, BakingPowder)
val possibleMixture = checkAndMix(neededIngredients)
val possibleCake = possibleMixture.map(bake)


The function is applied only if the result is a “Right” value (the mixture exists); otherwise, the “Left” value (the missing ingredients) remains unchanged.

However, a different implementation of the bake function might account for potential baking issues:

def bake(mixture: Mixture): Either[BakingIssue, Cake]


In this case, the result introduces another domain disjunction. If we chain these operations, we end up with nested types:

val possibleCake:
  Either[MissingIngredients, Either[BakingIssue, Cake]]


Comparing this to our first implementation, the type has become complex and difficult to read. It would be much cleaner to have a type that clearly shows the final result – the cake – alongside any potential problems that occurred during preparation.

val idealCake:
  Either[OneOfTwo[MissingIngredients, BakingIssue], Cake]


This ideal solution combines the different negative paths into a single type where only one issue can be present at a time. Here is a simple implementation that converts a nested Either into a “flat” one:

sealed trait OneOfTwo[+A, +B]
case class First[A](a: A) extends OneOfTwo[A, Nothing]
case class Second[B](b: B) extends OneOfTwo[Nothing, B]
// convert
def convert[A, B, C](either: Either[A, Either[B, C]]):
  Either[OneOfTwo[A, B], C] = either.fold(
    a => Left(First(a)), {
      case Left(b) => Left(Second(b))
      case Right(c) => Right(c)
    }
)


This approach keeps our domain disjunctions organized on the left-hand side, leaving the right-hand side clear for our successful result: the cake.

Functional.Programming

Posted on by

I like to think of Functional Programming as another level of abstraction that pulls code further away from the physical machine, much like how automatic memory management once hid raw memory addresses from the developer. To me, Functional Programming is a guide for building applications without the need for manual memory assignments.

It is all about Immutability

What is the problem with memory assignment, or more specifically, mutable data?

In a world where software runs in parallel, shared mutable states are a massive problem. Countless solutions have been built to address this, but they usually involve synchronization, locks, and waiting – all of which lead to performance and scalability bottlenecks.

Another way to solve the problem is to avoid it entirely by writing software without shared mutable states. This means using exclusively immutable data structures. In this context, a paradigm that thrives on immutability becomes very attractive. Functional Programming fits this role perfectly; it acts as a discipline that abstracts software away from the constant need for memory assignments.

Be Functional

The core principle of Functional Programming is transformation: a function takes an input, applies a logic, and returns an output. This approach has the same expressive power as imperative code but offers tools and patterns that guide developers to work within this different paradigm.

Let’s compare an imperative example of finding the maximum value in a list with a functional version:

Imperative Approach:

List<Integer> list = Arrays.asList(3, 6, 5);
int max = Integer.MIN_VALUE;
for (int value : list) {
  if (value > max) max = value;
}


In this example, the imperative code uses a max variable to store and update the result.

Functional Approach:

int calculateMax(List<Integer> list, int max) {
  if (list.isEmpty()) return max;
  else {
    int head = list.get(0);
    List<Integer> tail = list.subList(1, list.size() - 1);
    int newMax = head > max ? head : max;
    return calculateMax(tail, newMax);
  }
}
List<Integer> list = Arrays.asList(3, 6, 5);
calculateMax(list, Integer.MIN_VALUE);


While the imperative version relies on re-assignment, the functional version relies on passing the state through parameters. Concepts like pipelines, higher-order functions, and composition simply make this data transformation more efficient and easier to manage.

Be Pure

An entire application can be viewed as a single, massive function. Since a thousand-line function is obviously bad practice, we modularize: functions are composed to create larger transformations. Simply put, composition is using the output of one function as the input for the next.

int f(double input) { ... }
String g(int input) { ... }
String output = g(f(1.2));


Pure functions are functions with no side effects. This means every observable effect is contained within the output. When you compose functions, the output defines the “interface” between them. If a function throws an unhandled exception, it breaks that interface and falls out of the transformation flow.

Be Typed

A typed language helps define a function’s signature. The more precise the type, the safer the composition. The type system acts as the contract between functions, allowing the compiler to handle a significant portion of the software validation for you.