Modéliser l’absence de valeur en TypeScript – Pattern Null-object

const nullTesterDoer = {
  canDo: () => false,
  do() {}
};

Cas concrets

Employee

Il s’agit de l’exemple, proposé par Oncle Bob, que j’ai un peu revisité. On cherche à récupérer depuis la base un Employee en utilisant la fonction findEmployee(by: (x: Employee) => boolean) prenant en paramètre un prédicat de recherche. Que faire quand aucun Employee n’est trouvé ?

1. Émettre une Error ? C’est envisageable quand on cherche un Employee par Id car on s’attend à ce qu’il existe. En revanche ici, on sait que notre fonction générique de recherche peut ne rien trouver, il faut donc indiquer cette absence de valeur d’une manière propre.
2. Renvoyer null ? Alors le type de retour sera Employee | null et le code appelant devra gérer explicitement ce null, sinon 💥.
3. Utiliser un type de retour qui indique cette absence de valeur ? Oui, nous étudierons cette piste prometteuse dans le prochain article.
4. Renvoyer un NullEmployee ? Voyons cela.

Le type Employee a une interface simple qui sert pour la paie, sachant qu’un employé est payé soit le vendredi, soit le dernier jour du mois :

interface Employee {
  isDayOfThePay(date: Date): boolean;
  pay(): void;
}

On retrouve le pattern Tester-Doer, compatible avec un Null-object : il suffit que isDayOfThePay() renvoie tout le temps false pour ne pas déclencher la paie de l’employé.

Folder

Imaginons une fonction getFolder(path: string) qui renvoie un objet Folder avec un nom et un répertoire parent. Le répertoire racine n’a pas de parent. Comment modéliser cette absence de valeur ?

• On l’indique habituellement par un champ optionnel parent?: Folder.
• On pourrait aussi proposer un type union Folder | RootFolder avec RootFolder sans champ parent.

Dans les deux cas, cela augmente la complexité cyclomatique du code appelant devant gérer les deux types de répertoires. Tentons un Null-object qui sera utilisé en tant que parent du répertoire racine et pour indiquer un répertoire non trouvé.

interface Folder {
  readonly name: string;
  readonly parent: Folder; // 👈 Obligatoire → Null-object pour le répertoire racine
}

const nullFolder: Folder = {
  name: '',
  parent: ???, // 👈 ❓
};

Quelle valeur choisir pour le parent du nullFolder ?

• ❌ parent: null → non seulement cela ne compile pas (car parent n’est pas “nullable”) mais cela contredit le pattern Null-object !
• ❌ parent: nullFolder → erreur de compilation « Block-scoped variable ‘nullFolder’ used before its declaration »
• ✔️ get parent() { return nullFolder; }

Désormais, cherchons à calculer la profondeur du répertoire. Rien de bien compliqué avec une fonction récursive :

function depth(folder: Folder): number {
  return 1 + depth(folder.parent);
}

Résultat : une belle erreur stack-overflow 💥 ! On voit les limites du pattern Null-Object, surtout quand on ne fait pas partout de l’OOP.

Justement, si l’on faisait plutôt de l’OOP ? Dans ce cas, depth n’est pas une fonction extérieure au type Folder mais un de ses membres, ici une propriété (plutôt qu’une méthode). Il suffit alors de surcharger cette propriété dans le Null-object, au prix d’un code plus verbeux :

class Folder {
  // ℹ Private nested class
  private static readonly _Null = class extends Folder {
    get depth() {
      return 0;
    }
  }

  static readonly Null: Folder = new Folder._Null('');

  constructor(
    readonly path: string,
    private readonly _parent?: Folder,
  ) { }

  get parent(): Folder {
    return this._parent ?? Folder.Null;
  }

  get depth(): number {
    return 1 + this.parent.depth;
  }
}

// Tests
const root = new Folder('/');
const a = new Folder('/a', root);
const b = new Folder('/a/b', a);

console.log([Folder.Null, root, a, b].map(x => [x.path, x.depth]));
// [LOG]: [["", 0], ["/", 1], ["/a", 2], ["/a/b", 3]] 

Null-object explicite

Faisons un compromis sur le côté “transparent pour le client” et permettons-lui de savoir que l’objet qu’il manipule est “vide”. La façon la plus simple consiste alors à ajouter un champ isEmpty.

Nous disposons d’un exemple en C♯ avec la classe DirectoryInfo prenant un chemin en entrée et renvoyant un objet indiquant par sa propriété Exists si le dossier a été trouvé ou non. Dans le cas d’un répertoire “vide”, les dates CreationTimeUtc, LastAccessTimeUtc et LastWriteTimeUtc ont bien une valeur “vide” mais pas celle à laquelle je m’attendais : j’ai obtenu 01/01/1601 00:00:00 ce qui est l’epoch de NTFS de mon poste Windows plutôt que celle de .NET (01/01/0001 00:00:00 – cf. DateTime.MinValue).

Voyons si un tel objet est sympa à utiliser. Considérons la fonctionnalité consistant à envoyer un mail à un client. Dans une application Angular, on pourrait l’implémenter de cette manière :

export class MailSenderService {
  constructor(
    private readonly clientRepository: ClientRepository,
    private readonly mailTemplateRepository: MailTemplateRepository,
  ) {}

  sendMail(clientId: string, mailTemplateId: string): boolean {
    // Null-object explicit
    const client = this.clientRepository.find(clientId);
    if (!client.exists) {
      return false;
    }

    // Objet nullable
    const mailTemplate = this.mailTemplateRepository.find(mailTemplateId);
    if (mailTemplate == null) {
      return false;
    }

    return this.performSendMail(client, mailTemplate);
  }

  private performSendMail(): boolean {
    // ...
  }
}

Ce service dépend de 2 repositories pour récupérer le client et le template de mail. Leur méthode find ne se comporte pas pareil :

• Celle de ClientRepository renvoie un objet non nullable mais pouvant être “vide”, l’indiquant avec le champ exists.
• Celle de MailTemplateRepository renvoie un objet nullable.

En fin de compte, les deux usages sont similaires : le code appelant doit vérifier si l’objet reçu est vide ou null. Ce type de null-object explicite n’a donc pas un grand intérêt. Ce n’est donc pas la bonne approche.

Quid d’inverser le contrôle ? En effet, un objet implémentant le null-object sait qu’il est vide. Il suffit donc de lui déléguer l’action à effectuer lorsqu’il n’est pas vide. Dans notre cas, cela peut prendre la forme d’une méthode whenExists(action: () => void): void. L’action est déclenchée par l’objet non-vide mais pas par l’objet vide. Voyons ce que cela donne à l’usage, en ayant modifié la méthode find de MailTemplateRepository pour y renvoyer un tel null-object :

export class MailSenderService {
  // ...
  sendMail(clientId: string, mailTemplateId: string): boolean {
    let result = false;

    const client = this.clientRepository.find(clientId);
    client.whenExists(() => {
      const mailTemplate = this.mailTemplateRepository.find(mailTemplateId);
      mailTemplate.whenExists(() => {
        result = this.performSendMail(client, mailTemplate);
      });
    });

    return result;
  }
  // ...
}

Bilan : même si la complexité cyclomatique descend de 3 à 1, je trouve que le code est moins facile à lire du fait de l’imbrication des callbacks et de la mise à jour de la variable result au milieu de tout cela. Arf ! Le retour du Callback hell ! 😱

Mais il faut « raison garder ». J’ai fait exprès de prendre ce cas pour montrer les limites du pattern. Dans un cas plus simple (ni template de mail, ni valeur de retour), le pattern est tout à fait adapté et le code est à la fois lisible et de faible complexité cyclomatique :

export class MailSenderService {
  // ...
  sendMail(clientId: string): void {
    const client = this.clientRepository.find(clientId);
    client.whenExists(() => this.performSendMail(client));
  }
  // ...
}

Quand on a plusieurs fois ce dernier type de cas, on peut utiliser les mixins pour en généraliser l’implémentation.

Null-object mixins

Les mixins servent à combiner plusieurs comportements au sein d’un même objet. Ils permettent de contourner l’absence d’héritage multiple.

Il existe deux manières d’implémenter des mixins en TypeScript : soit à base de class et d’héritage, soit directement sur l’objet cible.

Class mixin

Le comportement que l’on va “mixer” correspond à l’interface suivante :

interface INullObject {
  readonly exists: boolean;
  whenExists(action: () => void): void;
}

Pour montrer le fait que l’on peut appliquer plusieurs mixins, on la sépare en deux. On en profite pour proposer le comportement complémentaire :

interface INullObject {
  readonly empty: boolean;
  readonly exists: boolean;
}

interface IReactiveNullObject {
  whenEmpty(action: () => void): void;
  whenExists(action: () => void): void;
}

Un mixin est une fonction qui :

• Prend une classe en entrée,
• Renvoie une nouvelle classe étendant celle en entrée avec un nouveau comportement.

Quand on parle de classe ici, il ne s’agit pas du type, au niveau TypeScript. Le mixin opère au niveau JavaScript, au runtime, ce qui oblige à enlever le sucre syntaxique des class et à considérer la fonction constructeur utilisée pour implémenter une instance de la classe, représentée par le type Constructor :

type Constructor<T = {}> = new (...args: any[]) => T;

Pour correspondre aux deux cas de figure, “vide” (empty) ou “non-vide” (existing), nous sommes amenés à créer 4 mixins :

// Null-object mixins: NullObject
interface INullObject {
  readonly empty: boolean;
  readonly exists: boolean;
}

function NullObjectEmpty<TBase extends Constructor>(Base: TBase) {
  return class NullObjectEmpty extends Base implements INullObject {
    readonly empty = true;
    readonly exists = false;
  };
}

function NullObjectExisting<TBase extends Constructor>(Base: TBase) {
  return class NullObjectExisting extends Base implements INullObject {
    readonly empty = false;
    readonly exists = true;
  };
}

// Null-object mixins: ReactiveNullObject
interface IReactiveNullObject {
  whenEmpty(action: () => void): void;
  whenExists(action: () => void): void;
}

function ReactiveNullObjectEmpty<TBase extends Constructor>(Base: TBase) {
  return class ReactiveNullObjectEmpty extends Base implements IReactiveNullObject {
    whenEmpty(action) { action(); }
    whenExists() { }
  };
}

function ReactiveNullObjectExisting<TBase extends Constructor>(Base: TBase) {
  return class ReactiveNullObjectExisting extends Base implements IReactiveNullObject {
    whenEmpty() { }
    whenExists(action) { action(); }
  };
}

En pratique, on applique un seul mixin, le normal ou le réactif, selon la manière souhaitée de gérer le null-object. Pour notre exemple, nous allons combiner les mixins normaux et réactifs correspondant à leur cas respectif, empty ou existing :

interface IClient {
  readonly id: string;
  readonly name: string;
}

const Client =
  ReactiveNullObjectExisting(
    NullObjectExisting(
      class Client implements IClient {
        constructor(
          readonly id: string,
          readonly name: string,
        ) { }
      }));

const EmptyClient =
  ReactiveNullObjectEmpty(
    NullObjectEmpty(
      class EmptyClient implements IClient {
        readonly id = '';
        readonly name = '';
      }));

Procédons à un test rapide pour évaluer comment cela se comporte :

const c1 = new Client('C123', 'Romain');
const c2 = new EmptyClient();

[c1, c2].forEach((client, index) => {
  console.log(`Client n°${index + 1} » is empty: ${client.empty}`);
  client.whenExists(() => console.log(`» id: ${client.id}, name: ${client.name}`));
});

// Console output
// > Client n°1 » is empty: false
// > » id: C123, name: Romain
// > Client n°2 » is empty: true

L’IntelliSense se comporte bien lors de l’instanciation (new Client()) où les arguments sont bien indiqués : Client(id: string, name: string)). Cependant, le résultat n’est pas terrible pour les variables c1 et c2 :

const c1: ReactiveNullObjectExisting<{
    new (...args: any[]): NullObjectExisting<typeof Client>.NullObjectExisting;
    prototype: NullObjectExisting<any>.NullObjectExisting;
} & typeof Client>.ReactiveNullObjectExisting & NullObjectExisting<...>.NullObjectExisting & Client

const c2: ReactiveNullObjectEmpty<{
    new (...args: any[]): NullObjectEmpty<typeof EmptyClient>.NullObjectEmpty;
    prototype: NullObjectEmpty<any>.NullObjectEmpty;
} & typeof EmptyClient>.ReactiveNullObjectEmpty & NullObjectEmpty<...>.NullObjectEmpty & EmptyClient

💡 Playground TypeScript associé

On peut améliorer cela avec une interface Client désignant le type final et un namespace du même nom exposant la fonction Factorycreate() et le Singletonempty, l’ensemble permettant de masquer les détails d’implémentation :

interface ClientInfo {
  readonly id: string;
  readonly name: string;
}

interface Client extends ClientInfo, INullObject, IReactiveNullObject {}

namespace Client {
  class ClientImpl implements ClientInfo {
    constructor(
      readonly id: string,
      readonly name: string,
    ) { }
  }

  const ClientCtor = ReactiveNullObjectExisting(NullObjectExisting(ClientImpl));
  const EmptyClientCtor = ReactiveNullObjectEmpty(NullObjectEmpty(ClientImpl));

  export const create = ({ id, name }: ClientInfo): Client => new ClientCtor(id, name);
  export const empty: Client = new EmptyClientCtor('(empty)', '');
}

// Usage
const c1 = Client.create({ id: 'C123', name: 'Romain' });
const c2 = Client.empty;

// Null-object mixins: NullObject
interface INullObject {
  readonly empty: boolean;
  readonly exists: boolean;
}

const nullObjectEmpty: INullObject    = Object.freeze({ empty: true, exists: false });
const nullObjectExisting: INullObject = Object.freeze({ empty: false, exists: true });

// Null-object mixins: ReactiveNullObject
interface IReactiveNullObject {
  whenEmpty(action: () => void): void;
  whenExists(action: () => void): void;
}

const reactiveNullObjectEmpty: IReactiveNullObject = {
  whenEmpty(action) { action(); },
  whenExists() { }
};

const reactiveNullObjectExisting: IReactiveNullObject = {
  whenEmpty() { },
  whenExists(action) { action(); }
};

// Client
interface ClientInfo {
  readonly id: string;
  readonly name: string;
}

interface Client extends ClientInfo, INullObject, IReactiveNullObject {}

namespace Client {
  class ClientImpl implements ClientInfo {
    constructor(
      readonly id: string,
      readonly name: string,
    ) { }
  }

  export const create = ({ id, name }: ClientInfo): Client =>
    Object.assign(
      new ClientImpl(id, name),
      reactiveNullObjectExisting,
      nullObjectExisting);

  export const empty: Client = Object.freeze({
    id: '(empty)',
    name: '',
    ...reactiveNullObjectEmpty,
    ...nullObjectEmpty,
  });
}

// Usage
const c1 = Client.create({ id: 'C123', name: 'Romain' });
const c2 = Client.empty;

[c1, c2].forEach((client, index) => {
  console.log(`Client n°${index + 1} » is empty: ${client.empty}`);
  client.whenExists(() => console.log(`» id: ${client.id}, name: ${client.name}`));
});