Fluent Plain Old Object Builder Interface Pattern
Tags: oop, fluent, builder
Published: 2018-11-05 06:23:55

---
title: Fluent Plain Old Object Builder Interface Pattern
published: true
description: Plain Old Objects, Builder Patterns, and the application of the fluent interface concept to these.
tags: oop, fluent, builder
cover_image: https://thepracticaldev.s3.amazonaws.com/i/zc0482dtepnp9sob5qo9.jpg
---

The title of this article is actually a combination of the following concepts I want to talk about:

* Plain Old Object
* Builder Pattern
* Fluent Interface

These three are quite related and often mixed, but generally not all three at once. So lets talk about what they actually are.

*Note:* this article uses Java as its base language, but the ideas apply to any object oriented environment.


# Plain Old Object

This is an object that just holds data, it does not contain any business logic. In the Java world this type of object is generally called a POJO (Plain Old Java Object).

```java
public class Email {
    String subject;
    String body;
    String sender;
    String receiver;

    public String getSubject() {
        return subject.
    }

    public void setSubject(String aSubject) {
        subject = aSubject;
    }

    ...
}
```

It just contains fields and the means to read and write those fields. A plain old object should not contain methods which contain so called business logic. For example, it should not have a method like `send()` to send the email, or `delete()` to delete the method. And these methods would imply the plain old object has knowledge about communication and persistent storage mechanisms.

It could contain methods can tell some basic about the data is holds. For example a method `boolean hasBody()` would not be considered business logic. As long as the methods of the plain object only interact with the object itself it would not be considered business logic. (There is always the question when you want to move this logic out of this object and into a business logic oriented object. But that is a different subject.)

Plain Old Objects are generally used for models in model-view-controller setups, for persisted data, and for [parameter objects](https://refactoring.com/catalog/introduceParameterObject.html).

# Builder Pattern

The [builder pattern](https://en.wikipedia.org/wiki/Builder_pattern) is a so called creational [software design pattern](https://en.wikipedia.org/wiki/Software_design_pattern). It is basically a system that allows you to feed it the ingredients and eventually create an instance of an object.

```java
public class EmailBuilder {
    String subject;
    String body;
    String sender;
    String receiver;

    public Email build() {
        Email email = new Email();
        email.setSubject(subject);
        ...
        return email;
    }

    public void withSubject(String aSubject) {
        subject = aSubject;
    }

    ...
}
```

The main idea behind using a builder is so that you can hide the concrete implementation of an object but still be able to create an instance of it via a public interface.

The builder would for example allow you to make the public interface of the *Email* object immutable, but still allow the internals of a framework to work with the concrete implementation as a plain old object. 

An other use case would be that the builder could return a different concrete implementation.

```java
public class SecureEmailBuilder extends EmailBuilder {
    public Email build() {
        SecureEmail email = new SecureEmail();
        email.setSubject(subject);
        ...
        return email;
    }
}
```

The calling logic does not know, nor care, what kind of *Email* subtype it receives when calling the `build()` method. 


# Fluent Interface

A [fluent interface](https://en.wikipedia.org/wiki/Fluent_interface) is not, like the previous two subjects, a type construction. It defines a way for defining the interface of methods. 

In a fluent interface methods perform a certain action and return an object to continue with. The end result would be a chained sequence of method calls which would read much like a single sentence.

Commonly fluent methods write a field on an object and return the object itself. But the could also return a different fluent object to continue on. 

## Fluent Builder

For example, if we make the above mentioned builder a fluent builder we would be able to write the following.

```java
emailBuilder.withSubject("Hello World").withSender("Me").withReceiver("You").build()
```

The interface of the methods of the builder where changed to return the builder itself.

```java
public class EmailBuilder {
    ...

    public EmailBuilder withSubject(String aSubject) {
        subject = aSubject;
        return this;
    }

    ...
}
```

You can make this fluent builder less verbose and drop with `with` prefix (or `set` if you went for that style), and then you would get:

```java
emailBuilder.subject("Hello World").sender("Me").receiver("You").build()
```

The last method, `build()`, is a terminating method as it stops the fluent interface.

This construction is used quite often in frameworks which provide a fluent API. Some good examples in the Java world are [jOOQ](https://www.jooq.org/) or [Apache Camel](https://camel.apache.org). But also the stream API of Java 8 follows this style. Or in the front-end world, jQuery is a good example.

## Fluent Plain Old Object

We could also change the Plain Old Object to have a fluent interface.

```java
public class Email {
    ...

    public Email setSubject(String aSubject) {
        subject = aSubject;
        return this;
    }

    ...
}
```

Now you could write a nice one-liner to create an *Email* object with all the data you wanted.

```java
new Email().setSubject("Hello World").setSender("Me") ...
```

But this is **not** good. The set method no longer bears the interface signature commonly expected from a set method as it no longer returns void. This can break interoperability with a lot of frameworks which expect the set method to not return anything. 

To make it play nice we basically need to add a second method for every setter.

```java
public class Email {
    ...

    public void setSubject(String aSubject) {
        subject = aSubject;
    }

    public Email withSubject(String aSubject) {
        setSubject(aSubject);
        return this;
    }

    ...
}
```

This sadly makes the class a bit more bloated, and also increased the maintainability. 

## Fluent Object

We can also make our Plain Old Object completely fluent. It would cease to be a plain old object though. But for various use-cases this might be much more interesting.

```java
public class Email {
    String subject;
    String body;
    String sender;
    String receiver;

    public String subject() {
        return subject.
    }

    public Email subject(String aSubject) {
        subject = aSubject;
        return this;
    }

    ...
}
```

Both the set and get method no longer have a prefix. The no-argument `subject()` method is the get method, and the single argument `subject(String)` method is the set method which also returns the Email object so you can chain another method call.


# My "Guidelines"

None of the above mentioned constructions are better than the other. There are always trade-offs you need to consider.

## Just Plain Old Objects
I generally stick to using Plain Old Objects for data holders which I expect to be persisted in a database, or converted to a static form for transmission (XML, JSON, etc.). For the simple reason that it will have the best framework support.


## Parameter Objects
For parameter objects I am generally more inclined to use more fluent objects. But often with some method duplication to not mess with overall style

```java
public class ParamObject {
    ...

    public void setFoo(String aFoo) {
        foo = aFoo;
    }

    public foo(String aFoo) {
        setFoo(aFoo);
        return this;
    }

    public String getFoo() {
        return foo;
    }

    ...
}
```

This object looks behaves like a plain old object, but also allows it to be used fluently

```java
doSomething(new ParamObject().foo("Hello").bar("world"))
```

## Builders

For builders I generally use the approach as presented for the *Fluent Builders* using *with* as a prefix for all the methods which write data. This way there is a clear distinction between methods which perform actions, and methods which just write data.

I do not use *set* as the prefix, as I would see that as setting a property of the builder, rather than defining a value of the object I am creating.

## Components

Components are not covered in this article, but I would like to mention them in my guidelines anyway. An example of a component would be a UI element, for example a button on a form, and the form itself.

Components are also objects, but absolutely no Plain Old Objects. Components obviously have properties. For the set methods I always return the component so I can chain various set actions in a single line.

```java
form.add(new Button("save").setEnabled(false).setType(ButtonType.SUBMIT));
```

## Fluent API

Obviously when you create a fluent API you will go full fluent. This also means that the objects returned in these fluent should be as purely fluent as possible. So no *set* or *get* methods for writing fields. Only the terminating call would return a "normal" object.