Tag Archives: Functional Programming

Functional Domain Programming Cookbook

Posted on by

In this article I will try to show how Typed Functional Programming can be used to represent a domain. I would run through a step by step example where different domains are modelled with types and subtypes and functions are used to transform one domain to the other.

Let’s consider the process to make a cake that is described in a recipe. The first thing 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 written in the recipe but we are not sure that we have all the ingredients in our kitchen. To express this situation we create another type.

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

With these two types we can define the first operation needed to start the cake.

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

The result of this function is the list of needed ingredients where can be present or missing. We could have used the Option type from the Standard library but it wouldn’t have had the same expressivity. In this case is clear we would like to know which ingredient is missing while None would have hidden this information.

The next part of the recipe is mixing the list of needed ingredients.

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

The checkAndMix function result can be either a mixture or a list of missing ingredients.

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

We could’ve have chosen another way to represent the result of the function. Instead of Either we could have created another type.

sealed trait Mixture
case class FullMixture(ingredients: List[Ingredient])
case class PartalMixture(present: List[Ingredient],
                         missing: List[Ingredient])

This solution can look correct and even more elegant than the first one but it is not valid for domain: if you don’t have all the ingredients for a cake you don’t start mixing, it would be a waste!

Either is actually the right solution because represent a disjunction of domains. A disjunction means that two completely differents domains have only one thing in common: they are both valid result of the function.

The last thing to do with the mixture will be baking.

def bake(mixture: Mixture): Cake

As you can see this function takes only the mixture as input and, from the domain point of view, is the right definition. In fact what we want to express is that, after we successfully mixed the ingredients, we can bake the mixture. The Either type from the standard library offers a solution that is perfect for this kind of situations: map on right.

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

The function is applied only if the result is correct (if it is right) and the left value remains as is.

Another possible implementation of the bake function could have possible baking issues.

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

Once again this solution can be applied only to the a mixture but the result has another domain disjunction.

val possibleCake1: Either[MissingIngredients, Cake]
// or
val possibleCake2: Either[MissingIngredients, Either[BakingIssue, Cake]]

If we compare the final result type of the two implementations we can see that the type is more complex and not so easy to read. Instead, it would be nicer something that clearly shows the final result, the cake, and the possible problems that we can have during the preparation.

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

This ideal solution type would combine the positive and negative transformation paths where the issues are listed in a single type but only one can be present.

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 one is a possible simple implementation that converts the nested Either in a flat one with all the issues or domain disjunctions on the right hand side.

Functional.Programming

Posted on by

I like to think about Functional Programming as another level of abstraction that brings the code far from the physical machine, maybe like the next step after the Memory Management that has hidden the memory location. I like to think about Functional Programming as a guidance to create an application without memory assignments.

It is all about Immutability

What is the problem with memory assignment; or in other words, what is the problem with mutable data? In a context where every software runs in parallel, shared mutable states are a problem, a big problem. Plenty of solutions has been built to solve it but at the end they all imply a sort of synchronization with locks and waitings and potentially performances and scalability issues.

Another way to solve the problem is by avoiding it in the first place, so writing a software without any shared mutable states; or in other terms, using exclusively immutable data structures.

In this context a paradigm that works well with immutability can very attractive. Functional Programming fits very well in this role and it can be seen like a discipline that helps to abstracts the software from the need of memory assignments.

Be Functional

How well Functional Programming fits with immutability? The base principle of Functional Programming is transformation: the function takes an input, applies a transformation and returns an output. This principle has the same expressivity of any imperative code based on memory allocations. Functional Programming offers tools, patterns and disciplines to guide the developer to code with this different paradigm that does not involve memory assignment.

Let’s compare an example of imperative code that calculates the biggest value in a list with the functional version.

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 the max variable to store the final result while the functional code uses the max parameter.

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);

All the other concepts around Functional Programming like pipelines, higher order functions, compositions make more efficient or easier working with immutable data but at end the idea is very simple and it is all about data transformation.

Be Pure

An entire application can be seen a single function, a huge complex function of thousand and thousand lines of code. It is clear that such a thing is not a good practice and luckily functions can be easily modularized: more than one function can be composed together to create a bigger transformation. A simple definition of function composition is using the output of one function as input of another one.

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

Pure functions are functions with no side effects: meaning, when a function is called all the observable effects are in the output. If you think about composition you can see how important is the role of the output because it defines the interface between the two functions. For example If the first function throws an Exception the second function would not be able to catch it and it would be out of the transformation flow.

Be Typed

A typed language helps to define the signature of a function: more the type is precise, more the composition is safe. The type assumes the role of interface between functions and consequently part of the software validation is done by the type system through the compiler.