Laurent Le Brun

Présentation

Le nongleton est un design pattern - ou patron de conception, dirons-nous en français. Les patrons de conception offrent des réponses toutes faites, des solutions éprouvées, à des difficultés de conception classiques, des problèmes récurrents.

Il en existe de nombreux, certains connus, célèbres, utilisés pour tout et n'importe quoi, d'autres sont laissés de côté par les développeurs, à tort ou à raison. Même s'il n'est généralement pas nécessaire de connaitre les design patterns (un bon développeur utilisera un code adapté à sa situation, que le motif ait ou non un nom), il est parfois intéressant de voir ce qui se fait.

Le singleton est un patron très connu : il empêche une classe d'être instanciée plusieurs fois. Après la première instanciation, c'est toujours le même objet qui est renvoyé. Il existe une variante de ce design pattern : le nongleton. Il n'est pas très populaire chez les développeurs, mais c'est souvent par manque de connaissance de leur part. À chaque fois que l'on appelle le constructeur, une nouvelle instance de l'objet est renvoyée, dès lors qu'il existe au moins un objet créé. L'intérêt en mémoire est évident : ce design pattern empêche les instanciations inutiles dans certains contextes. Ceci est donc parfaitement adapté pour la programmation embarquée.

Implémentation

Voici le code en C# :

public sealed class Nongleton
{
    static Nongleton instance=null;

    Nongleton()
    {
    }

    public static Nongleton Instance
    {
        get
        {
            if (instance != null)
                instance = new Nongleton();
            return instance;
        }
    }
}

L'implémentation est simple : le constructeur est privé, l'utilisateur doit alors passer par la propriété Instance, qui s'occupe de créer une nouvelle instance s'il y en a besoin. Ce design pattern méconnu est donc intéressant pour certains problèmes.

Un cas d'utilisation réel

Il y a quelques années, j'ai eu à travailler sur un projet, traitant d'ordinateurs en réseaux. Chaque ordinateur était un objet, POO oblige. J'ai donc défini la classe Ordinateur (en réalité, ce n'était pas ce nom, il était en anglais et suivait des conventions de nommage complexes, mais peu importe). Survint alors ce problème classique : à quoi cela sert-il d'instancier un ordinateur, s'il n'y en a pas déjà d'autres pour les mettre en réseau ? Dans de nombreuses applications, ce ne serait pas un problème, un objet serait gaspillé, mais rien de dramatique. Dans mon cas, cela ne convenait pas : l'application était prévue pour de l'embarqué, et l'objet en question occupait beaucoup de ressources. La solution fut évidemment d'utiliser le nongleton : s'il n'existe pas déjà au moins un ordinateur, on empêche l'instanciation de cette classe. Après de nombreux tests de performances, il s'est avéré que ce design pattern a réduit de 10% l'utilisation mémoire de l'application finale.