Category Archives: Java

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.

Builder Pattern

Posted on by

In Java one of the most powerful ways to create an instance, except for dependency injection, is using the builder pattern.

The builder pattern helps to create immutable object and avoid to use long or many constructors.

The immutability in Java beans can be guaranteed defining all the attributes final, so once set, they remain the same and the status of the object never changes. As consequence, the constructor should set all the attributes and if there are a lot it can cause misleading set. This because Java constructors use only the position to identify the attributes and place the parameters in the wrong order is very easy, especially of the same type.

public class Person {
  private final String name;
  private final String surname;
  private final Integer age;

  public Person(String name, String surname, Integer age) {
    this.name = name;
    this.surname = surname;
    this.age = age;
  }

  public String getName() { return name; }

  public String getSurname() { return surname; }

  public Integer getAge() { return age; }

}

In this example is easy to declare the Person class with name and surname inverted.

To avoid this problem is possible to use a second class, the Builder, where the constructor is replaced with methods with meaningful names.

public class Builder {

  private String name;
  private String surname;
  private Integer age;

  public Builder withName(String name) {
    this.name = name;
    return this;
  }

  public Builder withSurname(String surname) {
    this.surname = surname;
    return this;
  }

  public Builder withAge(Integer age) {
    this.age = age;
    return this;
  }

  public Person build() {
    return new Person(name, surname, age);
  }

}

The Builder class contains the attributes values until the object is built and each parameter is set through a method.

Person person = new Builder()
  .withName("Alessandro")
  .withSurname("Simi")
  .withAge(32)
  .build();

The disadvantage of this solution (although is a good solution) is the Builder in itself, because requires to have another object and it doesn’t guarantee is used instead of the Person constructor.

To improve the solution the Builder can be defined as inner class of the Person table and reduce the visibility of the constructor, so the object can be created only through the Builder.

public class Person {
  ...
  private Person(String name, String surname, Integer age) {
  ...
  public static class Builder {
    ...
  }
}

Still this solution has two drawbacks. First, the object can be built before all the parameters are set. Second, the Builder is not immutable.

Solving the first problem means introducing a chain of Builders where only the leaf contains the build method. This approach can, for example, divides the mandatory attributes from the optional ones and in general can be expressed through a Fluent Interface.

The immutability can be possible if every method return a new instance of the Builder, but can produce a lot of boilerplate code.

public class Person {
  private final String name;
  private final String surname;
  private final Integer age;

  private Person(String name, String surname, Integer age) {
    this.name = name;
    this.surname = surname;
    this.age = age;
  }

  public String getName() { return name; }

  public Integer getAge() { return age; }

  public String getSurname() { return surname; }

  public static AfterName name(String name) {
    return new Person(name, null, null).new AfterName();
  }

  public class AfterName {
    public AfterAge age(Integer age) {
      return new Person(name, null, age).new AfterAge();
    }
  }

  public class AfterAge {
    public Builder surname(String surname) {
      return new Person(name, surname, age).new Builder();
    }
  }

  public class Builder {
    public Person build() {
      return Person.this;
    }
  }
}

This solution defines the Builder as inner class so it can access to the attributes and create a new instance for each method call. It also forces the creation when all the properties are set.