Si vous avez l’habitude de lire de la littérature autour dea programmation informatique, vous n’êtes certainement pas passé à côté des nombreux livres proposés aux Éditions ENI. En plus d’y retrouver mon livre “Kotlin, les fondamentaux du langage”, on retrouve dans leur bibliothèque des livres autour des patrons de conception (ou design patterns) en anglais. Et parmi ces livres, on en retrouve un qui présente par moins de 23 patrons de conception. Livre qui a d’ailleurs été décliné en 3 exemplaires pour adresser trois langages de programmation :

• Design Patterns en Java - Descriptions et solutions illustrées en UML 2 et Java - Les 23 modèles de conception ;
• Design Patterns en C# - Les 23 modèles de conception : descriptions et solutions illustrées en UML 2 et C# ;
• Design Patterns en PHP - Les 23 modèles de conception : descriptions et solutions illustrées en UML2 et PHP.

Bien évidemment, tous les langages de programmation permettent l’implémentation de patrons de conception. Ce n’est pas réservé au Java, au C# et au PHP. Si a première vue, dupliquer le contenu du livre trois fois pour ne changer que le langage de programmation utilisé peut sembler peu pertinent, c’est en réalité tout le contraire. En effet, chaque langage de programmation propose une syntaxe qui lui ait propre, des mots clefs spécifiques et parfois, des limitations. C’est pourquoi deux implémentations d’un même patron de conception peuvent être complètement différentes en fonction du langage de programmation utilisé.

Étant un amoureux du langage de programmation Kotlin, je vous propose donc une série d’articles dans lesquels le but est de proposer une implémentation Kotlin des 23 patrons de conception proposés dans ces livres.

Maintenant que l’introduction est faite, il convient de s’attaquer à du concret. Les 23 patrons de conception que nous allons voir dans cette suite d’articles peuvent être regroupés en grandes familles :

• Les patrons de construction ;
• Les patrons de structuration ;
• Les patrons de comportement ;

Débutons donc avec les patrons de construction.

Présentation

Les patrons de contruction (ou patterns de construction) ont un objectif simple : permettre l’abstraction de la création d’objets. Nous sommes donc ici sur une famille de patrons de conception qui s’appliquent aux langage permettant la programmation orientée objet. L’utilisation de cette famille de patrons de conception au sein d’un logiciel, lui permet d’être indépendant de ma façon dont les objets sont instanciés.

Pour permettre cette abstraction, comme souvent en programmation, le système d’interfaces est utilisé.

Créer des objets : où est le problème ?

Bien que chaque langage de programmation soit différent dans sa syntaxe et sa philosophie, on y retrouve cependant des éléments communs. Aussi, dans les langages de programmation permettant la programmation orientée objet, la création d’un objet se fait à travers l’invocation de ce que l’on appelle un constructeur qui, comme son nom le laisse deviner, permet de construire un objet en le paramétrant.

C’est notamment le cas du langage de programmation Kotlin qui utilise cette notion de constructeur. Aussi, en Kotlin, pour créer un objet, on utilise la syntaxe suivante :

val myObjet = MyClass()

Dans l’exemple ci-dessus, nous utilisons ce que l’on appelle un constructeur par défaut. Mais dans certains cas, l’utilisation de ce constructeur n’est pas suffisante et il est nécessaire de paramétrer cette création d’objet. Imaginons par exemple une méthode buildForm qui permet de créer les formes suivantes :

• carré ;
• triangle ;
• cercle.

Pour aider cette méthode, le type de la forme attendue est passé en paramètre sous la forme d’un nombre :

• 1 pour le carré ;
• 2 pour le triangle ;
• 3 pour le cercle.

On obtient alors le code suivant :

fun buildForm(id: Integee) : Form
{
 return if(id == 1)
 {
   Square()
 }
 else if(id == 2)
 {
   Triangle()
 }
 else if(id == 2)
 {
   Circle()
 }
}

Soyons francs, cet exemple est peu maintenable. L’utilisation d’une structure conditionnelle présente l’énorme inconvénient d’être peu robuste aux changements. En effet, si mon souhaite changer l’identifiant d’une forme ou si l’on souhaite supporter une nouvelle forme, il convient de changer le code de la méthode buildForm.

Les solutions proposées par les patterns de construction

Vous vous en doutez, le but de cet exemple est de mettre en avant une problématique que les patrons de construction vont nous permettre de résoudre. Dans le cadre de cette série d’articles, nous allons revenir sur 4 patrons de conception appartenant à la famille des patrons de construction :

• Le patron de conception Abstract Factory (ou Abstract Factory pattern en anglais ;
• Le patron de conception Builder (ou Builder pattern en anglais) ;
• Le patron de conception Factory Method (ou Factory Method pattern en anglais)
• Le patron de conception et Prototype (ou Prototype pattern en anglais).

3 de ces patrons de construction, les patrons de conception Abstract Factory, Builder et Prototype utilisent non pas un identifiant, mais un objet comme paramètre. Et c’est cet objet qui est en charge d’instancier des classes.

Le patron de conception Factory Method quant à lui a une toute autre approche puisqu’il se base sur le principe de sous-classes.

Nous allons bien évidemment revenir sur les détails de chacun de ces patrons de conception dans des articles dédiés