Skip to content

Development

The builder pattern

The builder software design pattern is an object creation one. It's a great building block for classes with optional fields. It provides a maintainable and readable way to instantiate immutable classes with more than 3 or 4 fields. It greatly reduces the time developers needs to understand how to instantiate the class properly.

You have surely faced one day or another a code similar to the one below.

public class Person {
  private final String firstname;
  private final String lastname;
  private final String address;
  private final String zipCode;

  public Person(final String firstname, final String lastname) {
    this(firstname, lastname, "");
  }

  public Person(final String firstname, final String lastname, final String address) {
    this(firstname, lastname, address, "");
  }

  public Person(final String firstname, final String lastname, final String address, final String zipCode) {
    this.firstname = Preconditions.nonNull(firstname);
    this.lastname = Preconditions.nonNull(lastname);
    this.address = Preconditions.nonNull(address);
    this.zipCode = Preconditions.nonNull(zipCode);
  }
}

Why objects must be Immutable

Immutable objects have multiple advantages over mutable objects which makes them the perfect building block to create software. You may already have many questions about the subject like:

  • Why should I use immutable over mutable objects?
  • How can I design software where no single object can be modified?

You'll see in this article what an immutable object is, the advantages to use them every time you can and how they can speed up your software developments.

Definition

To make it simple, a class is immutable when instances of this class cannot be changed once constructed. Immutable objects follow five rules, like explained in Java Effective by Joshua Bloch:

Final fields

No internal field can be reassigned after construction. This is very important: once the object has been constructed, there is no way to modify it.

public final class Truck {
 private final String brand;
 private final String model;
  ...
}

Angular2: filtering ngFor using pipes

Angular2 / Bootstrap4 table

I'm still working on a Stripe administration console for OctoPerf, a SaaS performance testing tool. Stripe lets us manage our customers and their subscriptions.

I have a table that lists all of our customers (Customers.html):

<table class="table table-striped">
  <thead class="thead-default">
  <tr>
    <th>#</th>
    <th>Id</th>
    <th>Email</th>
  </tr>
  </thead>
  <tbody>
  <tr *ngFor="#customer of customers; #i = index">
    <th scope="row">{{i}}</th>
    <td>{{customer.id}}</td>
    <td>{{customer.email}}</td>
  </tr>
  </tbody>
</table>

It's an Angular2 application build using this excellent starter with BootStrap 4.

Angular2: hard time unit testing Http requests

To follow up on my article about TypeScript generics in Angular2, I would like to unit test my Stripe client.

It involves mocking the Angular2 Http service, and it's far more complicated than unit testing the Router service. I first tried to inject a mock of the Http service and return custom Observable responses but this led to strange errors and cumbersome code.

I quickly switched to the recommended way, using MockBackend.

The service to test

As a remainder, the service tested is a Stripe client. It makes recursive Http request to Stripe API in order to fetch customers and plans: