Du coup, au grand mot les grands remèdes, en ce moment, je me mets à fond sur le C#, histoire de bien comprendre la syntaxe, et je compile petit à petit un tableau de ce qui me semble essentiel à savoir. En effet, qui n’est jamais tombé dans quelques pièges dus à des mots réservés qui, même s’ils existent dans les deux langages, ne veulent pas obligatoirement dire la même chose ?

Allez, pour vous et rien que pour vous, voici MON tableau à moi des différences notables et souvent secourables entre les deux langages majeurs du Framework !

Pas convaincu ? Un exemple un peu plus concret vous aiderait ? Ok, en voilà un parmis tant d’autres…

Imaginez une application de dessin. Dans votre barre de menu, entre autre, vous retrouvez un menu “Transformation”, qui permet d’effectuer différents traitements sur votre image tels que la rotation à 90° à droite, ou l’inversion des couleurs. Quelque chose de ce style, quoi :

Que diriez-vous de pouvoir augmenter les options de ce menu par la suite en mettant simplement une table à jour dans votre base de données, décrivant le nom de la commande et le code à exécuter ?

Et bien la méthode à utiliser est somme toute assez simple, mais quand on ne la connait pas, et bien… Ça ne s’invente pas !

Reprenons l’exemple de notre application de dessin. On peut raisonnablement estimer que pour chaque commande correspondant au menu transformation, la fonction qui exécutera le code correspondant devra prendre une image en argument, et renvoyer l’image transformée. On peut donc définir une partie du code de notre application (je n’expliquerai pas les parties de connexion à la base de données) :

Private _img As Image
 
Public Property Image() As Image
    Get
        Return Me._img
    End Get
    Set(ByVal value As Image)
        Me._img = Image
    End Set
End Property
 
Public Sub New()
 
    ' Requis par le Concepteur Windows Form.
    InitializeComponent()
 
    ' Création de la liste des transformation :
    ' - Le tag de chaque item contiendra l'identifiant en base de données.
    ' - On utilisera la méthode AddHandler pour gérer le clic sur un item
    '   avec la fonction tsmiTransformation_Click.
    InitLstTransformations()
 
End Sub
 
Private Sub tsmiTransformation_Click(ByVal sender As System.Object, ByVal e As System.EventArgs)
 
    'Récupération de l'item cliquée.
    Dim myItem As ToolStripMenuItem = TryCast(sender, ToolStripMenuItem)
    If myItem Is Nothing Then Exit Sub
 
    ' Récupération du code à exécuter qui est stocké en BDD.
    Dim vbCode As String = Me.getTransformationCode(myItem.Tag.ToString)
 
    Me.Image = ExecuteTransformation(vbCode, Me.Image)
 
End Sub

On sait que la fonction ExecuteTransformation aura le prototype suivant :

Private Function ExecuteTransformation(ByVal vbCode As String, ByVal img As Image) As Image

Bien ! Maintenant que le prototypage est fait, il ne reste plus grand chose… Ah ben si, on n’a toujours pas vu comment évaluer/exécuter la chaine vbCode comme si c’était du code VB !

J’ai dit que ce n’était pas très compliqué, mais si je vous donnais le code sans explication, vous pourriez trouver ça complexe ! Ben oui, les classes utilisées pour cette opération ne sont pas si courantes que ça… Mais pas de panique, après une brève explication de la démarche, vous trouverez ça aussi simple que compter jusqu’à 10 en binaires !

Dans le Framework .Net, à l’intérieur de l’espace de noms Microsoft.VisualBasic, se trouve une classe nommée VBCodeProvider. Cette classe vous “fournit un accès aux instances du générateur de code et du compilateur de code Visual Basic” (dixit la MSDN), ce qui veut dire que grâce à cette classe, vous allez pouvoir générer des assembly et/ou des exécutable .Net à partir d’une chaine représentant du code source VB.Net. Dans notre exemple, la génération d’un assembly pour chaque commande du menu transformation changerait rapidement le répertoire de notre application en un gigantesque foutoir. Sauf que VBCodeProvider permet également de générer ces assembly directement en mémoire ! Et donc, avec un peu d’imagination, d’exécuter du code à la volée ! Pour cela, on va donc utiliser un objet VBCodeProvider, ainsi qu’un objet CompilerParameters (je vous laisse regarder la MSDN) qui permet de configurer le compilateur VB. On va compiler une classe (appelons la EvalVbCode) qui contiendra une méthode (appelons la EvalTransformation) qui contiendra le code récupéré dans la base de données. Une fois l’assembly généré, il ne reste plus qu’à appeler la méthode (avec la Reflexion) et à récupérer l’image transformée… Simple, non ?!

Prêts ? Alors, prenez une bonne inspiration, et c’est parti :

Private Function ExecuteTransformation(ByVal vbCode As String, ByVal img As Image) As Image
    Dim vbCodeProv As VBCodeProvider = New VBCodeProvider
    Dim cParam As CompilerParameters = New CompilerParameters
 
    ' Ajout des références
    cParam.ReferencedAssemblies.Add("System.dll")
    cParam.ReferencedAssemblies.Add("System.Drawing.dll")
 
    ' Options du compilateur
    cParam.CompilerOptions = "/t:library"  'L'assembly est une bibliothèque de classe,
    cParam.GenerateInMemory = True         'générée uniquement en mémoire.
 
    ' Génération du code source
    Dim sCode As System.Text.StringBuilder = New System.Text.StringBuilder("")
    sCode.AppendLine("Imports System")
    sCode.AppendLine("Imports System.Drawing")
    sCode.AppendLine("Imports System.Diagnostics")
    sCode.AppendLine()
    sCode.AppendLine("Namespace VotreNamespace")
    sCode.AppendLine(vbTab & "Class EvalVbCode")
    sCode.AppendLine(vbTab & vbTab & "Public Function EvalTransformation(ByVal img As Image) as Image")
    sCode.AppendLine(vbTab & vbTab & vbTab & "Try")
    sCode.AppendLine()
    sCode.AppendLine(vbCode)
    sCode.AppendLine()
    sCode.AppendLine(vbTab & vbTab & vbTab & "Catch ex As Exception")
    ' En cas d'erreur : console de debug ET renvoie Nothing
    sCode.AppendLine(vbTab & vbTab & vbTab & vbTab & "Debug.WriteLine(ex.Message)")
    sCode.AppendLine(vbTab & vbTab & vbTab & vbTab & "Return Nothing")
    sCode.AppendLine(vbTab & vbTab & vbTab & "End Try")
    sCode.AppendLine(vbTab & vbTab & "End Function")
    sCode.AppendLine(vbTab & "End Class")
    sCode.AppendLine("End Namespace")
    ' Code de la classe dans la console de debug
    Debug.WriteLine(sCode.ToString())
 
    ' Résultat de la compilation
    Dim cResult As CompilerResults = vbCodeProv.CompileAssemblyFromSource(cParam, sCode.ToString())
    ' Récupération de l'assembly généré
    Dim myAssembly As System.Reflection.Assembly = cResult.CompiledAssembly
    ' Instanciation de EvalVbCode
    Dim oEvalVbCode As Object = myAssembly.CreateInstance("VotreNamespace.EvalVbCode")
    ' Récupération du type de EvalVbCode
    Dim tEvalVbCode As Type = oEvalVbCode.GetType()
    ' Récupération de la méthode EvalTransformation
    Dim methodEvalTrans As MethodInfo = tEvalVbCode.GetMethod("EvalTransformation")
    ' Invocation de la méthode EvalTransformation
    Dim myImage As Image = methodEvalTrans.Invoke(oEvalVbCode, New Object() {img})
 
    Return myImage
End Function

Et voilà ! Le code est exécuté à la volée ! N’oubliez pas d’indenter un minimum votre code, afin de pouvoir le lire dans la console de debug. Et maintenant, réfléchissez un peu plus aux applications d’une telle technique. Et n’oubliez pas que vous pouvez également générez les assembly et/ou applications sous forme de fichier sur le disque, puis utiliser la réflection pour les charger dynamiquement durant l’exécution de l’application.

Bon code !

Une mine d’or, je vous dis…

But

Séparer la construction d’un objet complexe de sa représentation, afin qu’un même processus de constrauction puisse créer différentes représentations.

Autre Nom

Builder

Exemple

Un lecteur pour le format d’échange de documents RTF (Rich Texte Format) devrait être capable de convertir le RTF vers de multiples formats textes. Le lecteur pourrait convertir des documents RTF en texte ASCII ou en un widget texte pouvant être édité interactivement. Le problème, cependant, est que le nombre de conversions possible est sans fin. Donc, on devrait pouvoir ajouter de nouvelles conversions sans modifier le lecteur.

Une solution serait de configurer la classe LecteurRTF avec un objet ConvertisseurDeTexte qui convertirait le RTF en une autre représentation textuelle. Pendant que le LecteurRTF analyse le document RTF, il utilise le ConvertisseurDeTexte pour effectuer la conversion. Chaque fois que le LecteurRTF reconnaît un motif RTF (que ce soit du texte simple ou un symbole de contrôle RTF), il fait une demande au ConvertisseurDeTexte pour convertir le motif. Les objets ConvertisseurDeTexte sont responsables tant de la conversion de données que de la représentation d’un motif dans un format particulier.

Les sous-classes de ConvertisseurDeTexte sont spécialisées dans différentes conversions vers différents formats. Par exemple, un ConvertisseurASCII ignore les demandes de conversion qui ne concernent pas du texte simple. D’un autre côté, un ConvertisseurTeX va implémenter des opérations pour toutes les requêtes afin de produire une représentation TeX qui va reproduire toutes les informations de style du texte. Un ConvertisseurWidgetTexte va produire un objet d’interface utilisateur complexe qui permettra à l’utilisateur de voir et d’éditer le texte.

Chaque type de classe de convertisseur va implémenter le mécanisme de création et d’assemblage d’un objet complexe en n’exposant qu’une interface abstraite. Le convertisseur est séparé du lecteur, qui est responsable de l’analyse du document RTF.

Le motif de conception Monteur prend en compte toutes ces relations. Chaque classe de convertisseur est appelée “monteur” dans le motif, et le lecteur est appelé le “directeur”. Appliqué à cet exemple, le Monteur sépare les algorithmes pour l’interprétation d’un format texte (c’est-à-dire l’analyseur de documents RTF) de la manière dont un format de conversion est créé et représenté. Cela nous permet de réutiliser l’algorithme d’analyse du LecteurRTF afin de créer différentes représentation de documents RTF : il suffit de configurer le LecteurRTF avec différentes sous-classes de ConvertisseurDeTexte.

Applicabilité

Utilisez le motif de conception Monteur quand :

• L’algorithme de création d’un objet complexe doit être indépendant des parties qui construisent l’objet et de comment celles-ci sont assemblées.
• Le processus de construction doit permettre différentes représentations de l’objet construit.

Structure

Participants

• Monteur (ConvertisseurDeTexte)
  • Spécifie une interface abstraite afin de créer les parties d’un objet Produit.
• MonteurConcret (ConvertisseurASCII, ConvertisseurTeX, ConvertisseurWidgetTexte)
  • Construit et assmble les pièces du produit en implémentant l’interface Monteur.
  • Définit et garde une trace de la représentation qu’il crée.
  • Fournit une interface pour retrouver le produit (i.e., GetTexteASCII, GetTexteWidget)
• Directeur (LecteurRTF)
  • Construit un objet en utilisant l’interface Monteur.
• Produit (TexteASCII, TexteTeX, TexteWidget)
  • Représente l’objet complexe en construction. MonteurConcret construit la représentation interne du produit et définit le processus par lequel il est assemblé.
  • Comprend les classes qui définissent les éléments constitutifs, y compris les interfaces pour l’assemblage des pièces en un résultat final.

Collaboration

• Le client crée l’objet Directeur et le configure avec l’objet Monteur désiré.
• Le Directeur notifie le Monteur à chaque fois qu’une partie du Produit doit être construite.
• Le Monteur gère les demandes du Directeur et ajoute des parties au Produit.
• Le client récupère le Produit auprès du Monteur.

Le diagramme d’interaction suivant illustre la manière dont le Monteur et le Directeur coopèrent avec le client.

Conséquences

Voici les principales conséquences du motif de conception Monteur :

1. Il permet de varier la représentation interne d’un produit. L’objet Monteur fournit une interface abstraite au Directeur pour la construction du produit. L’interface permet au monteur de cacher la représentation et la structure interne du produit. Elle cache également la manière dont est assemblé le produit. Comme le produit est construit au travers d’une interface abstraite, tout ce que vous avez à faire pour changer la représentation interne du produit est de définir un nouveau type de monteur.
2. Il isole le code de construction et le code de représentation. Le motif de conception Monteur améliore la modularité en encapsulant la manière dont un objet complexe est construit et représenté. Les clients n’ont pas besoin de savoir quoi que ce soit à propos de la classe qui définit la structure interne du produit ; ces classes n’apparaissent pas dans l’interface Monteur.Chaque MonteurConcret contient tout le code pour créer et assembler un certain type de produit. Le code n’est écrit qu’une fois ; puis différents Directeurs peuvent le réutiliser afin de construire des Produits dérivants d’un même ensemble de pièces. Dans l’exemple du RTF que l’on vient de voir, nous pourrions définir un lecteur pour un format autre que RTF, comme un LecteurSGML, et utiliser les même ConvertisseursDeTexte pour générer du TexteASCII, du TexteTeX ou du TexteWidget venant de documents SGML.
3. Il permet un meilleur contrôle du processus de construction. À la différence des motifs de création qui construisent un produit d’un seul coup, le motif de conception Monteur construit le produit étape par étape sous le contrôle du Directeur. Ce n’est que lorsque le produit est fini que le Directeur récupère le produit auprès du Monteur. On peut donc dire que l’interface Monteur reflète mieux le processus de construction d’un produit que les autres motifs de création. Cela permet un meilleur contrôle du processus de construction et, par conséquent, sur la structure interne du produit résultant.

Implémentation

Typiquement, il y a une classe abstraite Monteur qui définit une opération pour chaque composant que le Directeur pourrait lui demander de créer. Par défaut, ces opérations ne font rien. Une classe MonteurConcret surcharge les opérations concernant les composants dont la création l’intéresse.

Quelques autres questions à se poser sur l’implémentation :

1. Assemblage et construction d’interface. Les Monteurs construisent leurs produit dans un mode étape par étape. Par conséquent, l’interface de la classe Monteur doit être assez générale pour permettre la construction de produits pour tout type de MonteurConcret.L’une des principales questions de conception concerne le modèle pour le processus de construction et d’assemblage. Un modèle dans lequel les résultats des demandes de construction sont simpllement ajoutés les uns aux autres est habituellement suffisant. Dans l’exemple du RTF, le Monteur convertit et ajoute le motif suivant au texte qu’il a convertit jusqu’ici.Mais parfois, vous pourriez avoir besoin d’accéder à des parties du produit construit plus tôt. Dans l’exemple du Labyrinthe présenté au chapitre “Exemple de code”, l’interface MonteurDeLabyrinthe permet d’ajouter une porte entre des Pièces existantes. Les structures arborescentes comme les arbres d’analyse vus plus bas sont un autre exemple. Dans ce cas, le Monteur va renvoyer des noeuds enfants au Directeur, qui va ensuite les retourner au Monteur pour construire les noeuds parents.
2. Pourquoi ne pas rendre abstraites les classes de produits également ? Dans la plupart des cas, les produits construits par les MonteurConcret diffèrent tellement dans leur représentation qu’il y a très peu de gain à donner aux différents produits une classe parente commune. Dans l’exemple du RTF, les objets TexteASCII et TexteWidget sont trop différents pour avoir une interface commune, et n’en ont pas besoin. Comme le client va configurer le Directeur avec le bon MonteurConcret, le client est en position de savoir quelle sous-classe de Monteur est utilisée et peut gérer ses produits dans ce sens.
3. Par défaut, les méthodes du Monteur sont vides. En C++, les méthodes de construction ne sont intentionnellement pas déclarées comme de pures fonctions membres virtuelles. Au lieu de cela, elles sont définies comme des méthodes vide, laissant le client surcharger uniquement celles qui l’intéressent.

Exemple de code

On va définir une variante de la fonction NouveauLabyrinthe qui va prendre un monteur de type MonteurDeLabyrinthe en argument.

La classe MonteurDeLabyrinthe définit l’interface suivante pour construire des labyrinthes :

Class MonteurDeLabyrinthe
 
    Protected Sub New()
    End Sub
 
    Public Shared Sub MonteLabyrinthe()
    End Sub
 
    Public Shared Sub MontePièce(ByVal numPièce as Integer)
    End Sub
 
    Public Shared Sub MontePorte(ByVal dePièce as Integer, ByVal àPièce as Integer)
    End Sub
 
    Public Shared Function GetLabyrinthe() as Labyrinthe
        Return Nothing
    End Function
 
End Class

Cette interface peut créer trois choses : (1) le labyrinthe, (2) des pièces avec un numéro de pièce particulier, et (3) des portes entre des pièces numérotées. La fonction GetLabyrinthe retourne un labyrinthe au client. Les sous-classes de MonteurDeLabyrinthe vont surcharger ces opérations pour renvoyer le labyrinthe qu’elles auront construit.

Toutes les opérations de construction de labyrinthe de MonteurDeLabyrinthe ne font rien par défaut. Elles ne sont pas déclarées comme purement virtuelles afin de laisser aux classes dérivées le soin de surcharger uniquement les méthodes qui les intéressent.

Etant donné l’interface de MonteurDeLabyrinthe, on peut modifier la fonction NouveauLabyrinthe afin qu’elle prenne ce Monteur en paramètre.

Public Function NouveauLabyrinthe(monteur as MonteurDeLabyrinthe) as Labyrinthe
 
    monteur.MonteLabyrinthe()
 
    monteur.MontePièce(1)
    monteur.MontePièce(2)
    monteur.MontePorte(1, 2)
 
    Return monteur.GetLabyrinthe()
 
End Function

Comparez cette version de NouveauLabyrinthe à l’originale. Notez bien comment le Monteur cache la représentation interne du labyrinthe (c’est-à-dire, les classes qui définissent les pièces, les portes et les murs), et comment ces parties sont assemblées pour produire le labyrinthe final. On peut deviner qu’il existe des classes pour les pièces et les portes, mais aucun indice ne laisse à penser qu’il en existe pour les murs. Cela permet de changer plus facilement la manière dont un labyrinthe est représentée, puisque aucun des clients de MonteurDeLabyrinthe n’a besoin d’être modifié.

Comme les autres motifs de création, le motif de conception Monteur encapsule la manière dont les objets sont créés, dans ce cas : au travers de l’interface définie par MonteurDeLabyrinthe. Cela signifie que l’on peut réutiliser MonteurDeLabyrinthe afin de construire différents types de labyrinthes. La fonction NouveauLabyrintheComplexe en donne un exemple :

Public Function NouveauLabyrintheComplexe(monteur as MonteurDeLabyrinthe) as Labyrinthe
 
    monteur.MonteLabyrinthe()
 
    monteur.MontePièce(1)
    monteur.MontePièce(2)
    '...
    monteur.MontePièce(1001)
 
    Return monteur.GetLabyrinthe()
 
End Function

Notez bien que MonteurDeLabyrinthe ne crée pas le labyrinthe lui-même ; son but principal est simplement de définir une interface pour la création de labyrinthes. Il définit une implémentation vide principalement par commodité. Les classes dérivées de MonteurDeLabyrinthe font le véritable travail.

La sous-classe MonteurDeLabyrintheStandard est une implémentation qui construit de simples labyrinthes. Elle garde une trace du labyrinthe qu’elle construit dans la variable _labyrintheCourant.

Class MonteurDeLabyrintheStandard
    Inherits MonteurDeLabyrinthe
 
    Private _labyrintheCourant as Labyrinthe
 
    Public Sub New()
        '...
    End Sub
 
    Public Shared Sub MonteLabyrinthe()
        '...
    End Sub
 
    Public Shared Sub MontePièce(ByVal numPièce as Integer)
        '...
    End Sub
 
    Public Shared Sub MontePorte(ByVal dePièce as Integer, ByVal àPièce as Integer)
        '...
    End Sub
 
    Public Shared Function GetLabyrinthe() as Labyrinthe
        '...
    End Function
 
    Private Function MurCommun(ByVal p1 as Pièce, ByVal p2 as Pièce) as Direction
        '...
    End Function
 
End Class

MurCommun est une fonction utilitaire déterminant la direction d’un mur commun entre deux pièces.

Le constructeur de MonteurDeLabyrintheStandard initialise simplement _labyrintheCourant.

Public Sub New()
    Me._labyrintheCourant = Nothing
End Sub

MonteLabyrinthe instancie un Labyrinthe que les autres opérations vont assembler et éventuellement retourne au client (avec GetLabyrinthe).

Public Sub MonteLabyrinthe()
    Me._labyrintheCourant = New Labyrinthe()
End Sub
 
Public Function GetLabyrinthe() as Labyrinthe
    Return Me._labyrintheCourant
End Function

La procédure MontePièce crée une pièce et construit les murs autour d’elle :

Public Shared Sub MontePièce(ByVal numPièce as Integer)
 
    If (Me._labyrintheCourant.PieceNo(numPièce) Is Nothing) Then
        Dim maPièce as Pièce = New Pièce(numPièce)
        Me._labyrintheCourant.AjouterPiece(maPièce)
        maPièce.Cote(Nord) = New Mur()
        maPièce.Cote(Sud) = New Mur()
        maPièce.Cote(Est) = New Mur()
        maPièce.Cote(Ouest) = New Mur()
    End If
 
End Sub

Pour construire une porte entre deux pièces, MonteurDeLabyrintheStandard prend les deux pièces dans le labyrinthe et trouve leur mur commun :

Public Shared Sub MontePorte(ByVal dePièce as Integer, ByVal àPièce as Integer)
 
    Dim p1 as Pièce = Me._labyrintheCourant.PieceNo(dePièce)
    Dim p2 as Pièce = Me._labyrintheCourant.PieceNo(àPièce)
    Dim po as Porte = New Porte(p1, p2)
 
    p1.Cote(MurCommun(p1, p2)) = po
    p2.Cote(MurCommun(p2, p1)) = po
 
End Function

Les clients peuvent maintenant utiliser NouveauLabyrinthe en conjonction avec MonteurDeLabyrintheStandard pour créer un labyrinthe :

Dim laby as Labyrinthe
Dim jeu as JeuDuLabyrinthe
Dim monteur as MonteurDeLabyrintheStandard
 
jeu.NouveauLabyrinthe(monteur)
laby = monteur.GetLabyrinthe()

On pourrait avoir mis toutes les opérations de MonteurDeLabyrintheStandard dans Labyrinthe et laissé chaque Labyrinthe se monter lui-même. Mais faire une plus petite classe Labyrinthe la rend plus simple à comprendre et à modifier, et MonteurDeLabyrintheStandard est facile à séparer de Labyrinthe. Plus important, séparer les deux permet d’avoir une multitude de MonteurDeLabyrinthe, chacun utilisant des classes différentes pour les pièces, les murs et les portes.

Un MonteurDeLabyrinthe plus exotique serait MonteurDeLabyrintheComptable. Ce monteur ne crée pas du tout de Labyrinthe ; il ne fait que compter les différents types de composants qui auraient été créés.

Class MonteurDeLabyrintheComptable
    Inherits MonteurDeLabyrinthe
 
    Private _portes as Integer
    Private _pieces as Integer
 
    Public Sub New()
        '...
    End Sub
 
    Public Shared Sub MonteLabyrinthe()
        '...
    End Sub
 
    Public Shared Sub MontePièce(ByVal numPièce as Integer)
        '...
    End Sub
 
    Public Shared Sub MontePorte(ByVal dePièce as Integer, ByVal àPièce as Integer)
        '...
    End Sub
 
    Public Shared Sub AjouterMur(ByVal numPièce as Integer, ByVal dir as Direction)
        '...
    End Sub
 
    Public Sub GetCompte(ByRef nbPortes as Integer, ByRef nbPièces as Integer)
        '...
    End Sub
 
End Class

Le constructeur initialise les compteurs, et les opérations surchargées de MonteurDeLabyrinthe s’occupent de les incrémenter comme il faut.

Public Sub New()
    Me._portes = 0
    Me._pieces = 0
End Sub
 
Public Shared Sub MontePièce(ByVal numPièce as Integer)
    Me._pieces = Me._pieces + 1
End Sub
 
Public Shared Sub MontePorte(ByVal dePièce as Integer, ByVal àPièce as Integer)
    Me._portes = Me._portes + 1
End Sub
 
Public Sub GetCompte(ByRef nbPortes as Integer, ByRef nbPièces as Integer)
    nbPortes = Me._portes
    nbPièces = Me._pieces
End Sub

Et voici comment un client pourrait utiliser un MonteurDeLabyrintheComptable :

Dim pieces as Integer
Dim portes as Integer
Dim jeu as JeuDuLabyrinthe
Dim monteur as MonteurDeLabyrintheComptable
 
jeu.NouveauLabyrinthe(monteur)
monteur.GetCompte(portes, pieces)
 
MsgBox("Le labyrinthe contient " & pieces & " pièces et " & portes & " portes.")

Utilisations connues

L’application de conversion RTF vient de ET++. Son bloc de construction de texte utilise un Monteur pour traiter le texte stocké au format RTF.

Monteur est un motif de conception commun en GNU Smalltalk :

• La classe Parser du système interne de compilation est un Directeur qui prend un objet ProgramNodeBuilder en argument. Un objet Parser notifie son objet ProgramNodeBuilder à chaque fois qu’il reconnaît une construction syntaxique. Quand l’analyse est terminée, Parser demande au monteur l’arbre d’analyse qu’il a construit et le retourne au client.
• ClassBuilder est un Monteur que les classes utilisent pour créer des sous-classes d’elles-même. Dans ce cas, une classe est à la fois le Directeur et le Produit.
• ByteCodeStream est un Monteur qui crée une méthode compilée en tant que tableau d’octets. ByteCodeStream est une utilisation non-standard du mitif de conception Monteur, parce que l’objet complexe qu’il construit est encodé comme un tableau d’octets, et non comme un objet SmallTalk standard. Mais l’interface de ByteCodeStream est typique du Monteur, et il serait très simple de remplacer ByteCodeStream par une classe différente représentant un programme comme un objet composé.

Le framework “Service Configurator” d’Adaptive Communications Environment utilise un Monteur afin de construire les composants de service réseau liés à un serveur en cours d’exécution. Les composants sont décrits avec un langage de configuration qui est analysé par un parser LALR. Les actions sémantiques de l’analyseur effectuent des opérations sur le Monteur qui ajoutent des informations au composant de service. Dans ce cas, l’analyseur est le Directeur.

Voir Aussi

La Fabrique Abstraite est similaire au Monteur en ce sens qu’elle construit elle aussi des objets complexes. La différence principale est que le motif de création Monteur se focalise sur la construction d’objets complexes, étape par étape. Fabrique Abstraite met l’accent sur les familles d’objets produits (qu’ils soient simples ou complexes). Pour le motif de conception Monteur, le retour du produit est la phase finale, tandis que Fabrique Abstraite le retourne immédiatement.

Un Objet Composite est ce que construit un Monteur la plupart du temps.

But

Fournir une interface pour la création de famille d’objets connexes ou dépendants sans indiquer leur classe concrète.

Autre Nom

Abstract Factory, Kit.

Exemple

Prenons un gestionnaire de composants d’interface utilisateur supportant un certain nombre de styles d’affichage, par exemple un style bleu et un style gris (comme les styles XP). Différents styles définissent différentes apparences et comportements pour les composants d’interface utilisateur tels que les barres de défilement, les fenêtres, et les boutons. Pour être portable sur les différents styles, une application ne devrait pas coder en dur ses composants pour un style particulier. L’instanciation de classes de composants spécifiques à un style au travers de l’application rendrait difficile la modification du style par la suite.

On peut résoudre ce problème en définissant une classe abstraite FabriqueDeComposants déclarant une interface pour créer chaque type basique de composant. On crée aussi une classe abstraite pour chaque type de composant, et les sous-classes concrètes qui vont implémenter chaque composant pour un style spécifique. L’interface de FabriqueDeComposants a une méthode qui renvoie un nouvel objet Composant pour chaque classe abstraite de composant. Les applications clientes font appel à ces méthodes pour obtenir des instances de composants, mais elles n’ont pas conscience de la classe concrète qu’elles utilisent. Par conséquent les applications clientes restent indépendantes du style sélectionné.

Il y a une sous-classe concrète de FabriqueDeComposants pour chaque style. Chaque sous-classe implémente les opérations pour créer les composants appropriés au style. Par exemple, la méthode CreerScrollBar de FabriqueDeComposantsBleus instancie et retourne une barre de défilement bleue, tandis que la même méthode dans la classe FabriqueDeComposantsGris renvoie une barre de défilement grise. Les applications clientes créent des composants uniquement via l’interface FabriqueDeComposants et n’ont pas connaissance des classes implémentant les composants pour un style donné. En d’autres termes, les applications clientes doivent seulement appliquer une interface définie par une classe abstraite, et non par une classe concrète particulière.

Une FabriqueDeComposants renforce également la cohésion entre les classes concrètes de composants. Une barre de défilement bleue doit être utilisée avec un bouton bleu dans une fenêtre bleue, et cette contrainte est automatiquement appliquée par l’utilisation de FabriqueDeComposantsBleus.

Applicabilité

Utilisez le motif Fabrique Abstraite quand :

• Un système doit être indépendant de la façon dont ses produits sont créés, composés et représentés.
• Un système doit être configurée avec l’une des multiples familles de produits.
• Des objets relatifs les uns aux autres sont fait pour être utilisés ensemble, et vous voulez renforcer cette contrainte.
• Vous voulez fournir une bibliothèque de classes de produits, et vous voulez juste donner leur interface, et non leurs implémentations.

Structure

Participants

• FabriqueAbstraite (FabriqueDeComposants) :
  • Déclare une interface de création de ProduitAbstrait.
• FabriqueConcrete (FabriqueDeComposantsBleus, FabriqueDeComposantsGris) :
  • Implémente les méthodes de création de ProduitConcret.
• ProduitAbstrait (ScrollBar, Fenetre, Bouton) :
  • Déclare une interface pour un type de produit.
• ProduitConcret (ScrollBarBleus, FenetreGris) :
  • Définit un produit devant être créé par la FabriqueConcrete correspondante.
  • Implémente l’interface ProduitAbstrait.
• Client :
  • Utilise uniquement les interfaces déclarées par les classes FabriqueAbstraite et ProduitAbstrait.

Collaboration

• Normalement, une seule instance d’une classe FabriqueConcrete est crée au moment de l’exécution. Cette FabriqueConcrete va créer des objets ayant une implémentation particulière. Pour créer des objets d’une implémentation différente, l’application Client doit utiliser une autre FabriqueConcrete.
• FabriqueAbstraite défère la création d’objet à ses sous-classes FabriqueConcrete.

Conséquences

Le motif Fabrique Abstraite génère les avantages et les inconvénients suivants :

1. Il isole les classes concrètes. Le motif Fabrique Abstraite vous aide à contrôler les classes d’objets qu’une application peut créer. Comme une fabrique encapsule la responsabilité et le processus de création des objets, il isole le client des classes d’implémentation. Le client va manipuler les instances au travers de leurs interfaces abstraites. Les noms des classes de produits concrets sont isolés dans l’implémentation des fabriques concrètes ; ils n’apparaissent pas dans le code client.
2. Il permet d’échanger facilement des familles de produit. La classe d’une fabrique concrète apparaît une seule fois dans l’application : là où elle est instanciée. Cela rend très simple le changement de fabrique utilisé par l’application. Le client peut utiliser différentes configurations de produits en modifiant simplement la fabrique concrète. COmme une fabrique abstraite crée une famille complète de produits, la famille entière de produit change en une seule opération. Dans notre example d’interface utilisateur, on peut passer des composants bleus aux composants gris en changeant simplement de fabrique de composant.
3. Il garantit la cohérence entre les produits. Quand les objets d’une famille sont fait pour travailler ensemble, il est important qu’une application n’utilise que les objets d’une seule famille à la fois. Fabrique Abstraite met facilement cela en oeuvre.
4. Il est difficile de prendre en charge de nouveaux types de produits. Etendre Fabrique Abstraite pour qu’elle supporte de nouveaux produits n’est pas facile. C’est parce que l’interface FabriqueAbstraite fixe l’ensemble de produits pouvant être créés. La prise en charge de nouveaux produits demande l’extension de l’interface de fabrication, ce qui implique de modifier la classe FabriqueAbstraite et toutes ses sous-classes. Nous discuterons d’une solution à ce problème dans la section suivante.

Implémentation

Quelques techniques utiles pour implémenter le motif Fabrique Abstraite :

1. Développer les fabriques en tant que Singleton. Une application à besoin, typiquement, d’une seule instance d’une FabriqueConcrete par famille de produit. Il est donc généralement préférable de les implémenter en tant que Singleton.
2. Créer les produits. FabriqueAbstraite déclare seulement une interface pour créer les produits. C’est aux sous-classes ProduitsConcrets de les créer. La méthode la plus utilisée de faire ceci est de définir une méthode de fabrication (voir Fabrique) pour chaque produit. Une fabrique concrète va spécifier l’implémentation de ses produits en surchargeant la méthode de fabrication pour chacun. Mais si cette implémentation est simple, elle demande une nouvelle classe de fabrique concrète pour chaque famille de produit, même si ces familles diffèrent très peu.

Si l’on risque d’avoir beaucoup de familles de produits, la fabrique concrète peut être implémentée en utilisant le motif Prototype. La fabrique concrète est initialisée avec une instance prototypique de chaque produit de la famille, et crée un nouveau produit en copiant ce prototype. Cette approche basée sur Prototype élimine le besoin d’une nouvelle classe de fabrique concrète pour chaque famille de produit.

Voici une manière d’implémenter une fabrique basée sur Prototype en SmallTalk. La fabrique concrète stocke les prototypes à cloner dans un dictionnaire appelé partCatalog. La méthode make: retrouve le prototype et le clone :

make: partName
       ^ (partCatalog at: partName) copy

La fabrique concrète a une méthode pour ajouter une pièce au catalogue :

addPart: partTemplate named: partName   partCatalog at: partName put: partTemplate

Les Prototypes sont ajoutés à la fabrique avec un identifiant :

aFactory addPart: aPrototype named: #ACMEWidget

3. Une variation de l’approche basée sur Prototype est possible dans les langages traitant les classes comme des objets de premier niveau (les langages orientés objets comme .Net, Java, C++, etc…). On peut voir une classe dans ces langages comme une fabrique dégénérée qui ne créerait qu’un seul type d’objet. On peut enregistrer ces classes dans une fabrique concrète qui crée les nombreux produits concrets en tant que variables, comme des prototypes. Ces classes vont créer de nouvelles instances à la place de la fabrique concrète. On définit une nouvelle fabrique en initialisant une instance de fabrique concrète contenant des classes de produits au lieu de sous-classer. Cette approche met à profit les caractéristiques de langage, au lieu de l’approche exactement basée sur Prototype, qui est indépendante du langage.Comme la fabrique basée sur Prototype dont on vient de parler en SmallTalk, la version basée sur les classes n’aura qu’une seule variable d’instance CatalogueDePièce, qui est un dictionnaire dont les clés sont les noms des pièces. Au lieu de conserver des prototypes à cloner, CatalogueDePièce enregistre les classes des produits. La méthode Créer ressemble maintenant à ça :

   make: partName
          ^ (partCatalog at: partName) new

4. Définir des fabriques extensibles. Fabrique Abstraite définit généralement une méthode différente pour chaque type de produit qu’elle peut fabriquer. Les types de produits sont encodés dans les signatures de ces méthodes. Ajouter un nouveau type de produit demande la modification de l’interface de FabriqueAbstraite et de toutes ses sous-classes.Une manière de faire, plus flexible mais moins sûre, est d’ajouter un paramètre aux méthodes de création d’objets. Ce paramètre spécifie le type d’objet à créer. Cela peut être un identifiant de classe, un entier, une chaine de caractères, ou n’importe quoi d’autre qui identifie le type de produit. Dans les faits, avec cette approche, FabriqueAbstraite n’a besoin que d’une méthode Creer avec un paramètre indiquant le type d’objet à créer. C’est la technique utilisée dans la fabrique abstraite basée sur Prototype évoquée ci-dessus.Cette variation est plus simple à utiliser dans un langage typé dynamiquement comme SmallTalk plutôt que dans un langage typé statiquement comme C++. Vous pouvez l’utiliser en C++ uniquement quand tous les objet ont la même classe abstraite de base, ou bien quand les produits peuvent être transtypés de manière sûre par le client qui les a demandés. La section Implémentation de la Fabrique montre comment implémenter de telles méthodes paramétrées en C++.Mais même quand le transtypage n’est pas requis, il reste toujours un problème : tous les produits sont retournés au client avec la même interface abstraite que le type de retour. Si le client a besoin d’appeler une méthode spécifique à la sous-classe, elle ne sera pas accessible au travers de cette interface abstraite. Même si le client peut effectuer une conversion (i.e. avec dynamic_cast, en C++), ce n’est pas toujours faisable ou sûr, parce que la conversion peut échouer. C’est le compromis classique d’une interface hautement flexible et extensible.

Exemple de code

On va appliquer le motif Fabrique Abstraite à la création de labyrinthes discutée au début de ce chapitre.

La classe FabriqueDeLabyrinthe peut créer des composants de labyrinthes. Elle construit des pièces, des murs, et des portes entre les pièces. Elle peut être utilisée par un programme qui lit des plans de labyrinthe depuis un fichier, et construit le labyrinthe correspondant. Ou elle peut être utilisée par un programme qui construit des labyrinthes de manière aléatoire. Ces programmes construisant des labyrinthes prennent une FabriqueDeLabyrinthe en argument de manière à ce que le programmeur puisse spécifier les classes de pièces, de murs et de portes à construire.

Class FabriqueDeLabyrinthe
    Public Sub New()
    End Sub
 
    Public Shared Function CreerLabyrinthe() As Labyrinthe
        Return New Labyrinthe
    End Function
 
    Public Shared Function CreerMur() As Mur
        Return New Mur
    End Function
 
    Public Shared Function CreerPiece(ByVal n As Integer) As Pièce
        Return New Pièce(n)
    End Function
 
    Public Shared Function CreerPorte(ByVal p1 As Pièce, ByVal p2 As Pièce) As Porte
        Return New Porte(p1, p2)
    End Function
 
End Class

Souvenez-vous de la fonction NouveauLabyrinthe qui construit un petit labyrinthe de deux pièces séparées par une porte. NouveauLabyrinthe code “en dur” les noms des classes, ce qui rend difficile la création de labyrinthes avec d’autres composants.

Voici une version de NouveauLabyrinthe qui va remédier à ce défaut en prenant une FabriqueDeLabyrinthe en paramètre :

Public Function NouveauLabyrinthe(fabrique as FabriqueDeLabyrinthe) as Labyrinthe
    Dim oLabyrinthe as Labyrinthe = fabrique.CreerLabyrinthe()
 
    Dim oPiece1 = fabrique.Pièce(1)
    Dim oPiece2 = fabrique.Pièce(2)
    Dim oPorte = fabrique.Porte(oPiece1, oPiece2)    oLabyrinthe.AjouterPiece(oPiece1)
    oLabyrinthe.AjouterPiece(oPiece2)
 
    oPiece1.Cote(Nord) = fabrique.Mur()
    oPiece1.Cote(Sud) = fabrique.Mur()
    oPiece1.Cote(Est) = oPorte
    oPiece1.Cote(Ouest) = fabrique.Mur()
 
    oPiece2.Cote(Nord) = fabrique.Mur()
    oPiece2.Cote(Sud) = fabrique.Mur()
    oPiece2.Cote(Est) = fabrique.Mur()
    oPiece2.Cote(Ouest) = oPorte
 
    Return oLabyrinthe
 
End Class

On peut créer une FabriqueDeLabyrintheEnsorcellé en sous-classant FabriqueDeLabyrinthe. FabriqueDeLabyrintheEnsorcellé va surcharger différentes fonctions et retourner différentes sous-classes de Pièce, Mur, etc.

Class FabriqueDeLabyrintheEnsorcellé
    Inherits FabriqueDeLabyrinthe
 
    Private Function JetteUnSort() As Boolean
        Dim oRnd As Random = New Random(CInt(DateTime.Now.Ticks))
 
        If oRnd.Next(0, 5) = 0 Then
            Return True
        Else
            Return False
        End If
 
    End Function
 
    Public Shared Function CreerPiece(ByVal n As Integer) As Pièce
        Return New PièceEnsorcellée(n, JetteUnSort())
    End Function
 
    Public Shared Function CreerPorte(ByVal p1 As Pièce, ByVal p2 As Pièce) As Porte
        Return New PorteAvecSort(p1, p2)
    End Function
 
End Class

Maintenant, supposons que l’on veuille faire un jeu de labyrinthe dans lequel les pièces peuvent contenir une bombe. Si la bombe explose, elle va endommager les murs. On peut créer une sous-classe de Pièce qui garde en mémoire si la pièce contient une bombe et si celle-ci a explosé ou non. Nous aurons également besoin d’une sous-classe Mur qui gardera une trace des dommages causés. Nous appellerons ces classes PiècePiégée et MurExplosé.

La dernière classa que nous définirons sera FabriqueDeLabyrinthePiégé, une sous-classe de FabriqueDeLabyrinthe qui s’assure que les murs sont de la classe MurExplosé et que les pièces sont de la classe PiècePiégée. FabriqueDeLabyrinthePiégée n’a besoin de surcharger que deux fonctions :

Class FabriqueDeLabyrintheEnsorcellé
    Inherits FabriqueDeLabyrinthe
 
    Public Shared Function CreerPiece(ByVal n As Integer) As Pièce
        Return New PiècePiégée(n)
    End Function
 
    Public Shared Function CreerMur() As Mur
        Return New MurExplosé()
    End Function
 
End Class

Pour construire un labyrinthe simple contenant des bombes, on va simplement appeler NouveauLabyrinthe avec une FabriqueDeLabyrinthePiégé.

Dim jeu as JeuDuLabyrinthe
Dim fabrique as FabriqueDeLabyrinthePiégé
 
jeu.NouveauLabyrinthe(fabrique)

NouveauLabyrinthe peut aussi bien recevoir une instance de FabriqueDeLabyrintheEnsorcellé afin de construire des labyrinthes ensorcellés.

Notez bien que la FabriqueDeLabyrinthe est juste une collection de éthodes de fabrication. C’est la manière la plus courante d’implémenter le motif Fabrique Abstraite. Notez également que FabriqueDeLabyrinthe n’est pas une classe abstraite ; même si elle agit aussi bien en tant que FabriqueAbstraite au’en tant que FabriqueConcrète. C’est une autre implémentation courante du motif Fabrique Abstraite. Comme la FabriqueDeLabyrinthe est une classe concrète consistant entièrement en des méthodes de fabrication, il est très simple de faire une nouvelle FabriqueDeLabyrinthe en créant une sous-classe et en surchargeant uniquement les méthodes qui en ont besoin.

NouveauLabyrinthe utilise la propriété Cote des pièces pour spécifier leurs côtés. Si cette méthode crée des pièces avec une FabriqueDeLabyrinthePiégé, alors le labyrinthe sera fait d’objets PiècePiégée avec des objets MurExplosé sur les côtés. Si PiècePiégée doit accéder à un membre spécifique à la sous-classe MurExplosé, alors elle devra convertir les références à ses murs de Mur à MurExplosé. Ce sous-classement est sûr tant que les murs sont bien des MurExplosé, ce qui est garanti si les murs sont construit grâce à FabriqueDeLabyrinthePiégé.

Les langages typés dynamiquement comme SmallTalk ne requièrent pas de sous-classement bien sûr, mais ils pourraient produire des erreurs de runtime s’ils rencontrent un Mur alors qu’ils attendaient une sous-classe de Mur. L’utilisation de Fabrique Abstraite aide à la prévention de ces erreurs en s’assurant que seuls certains types de murs peuvent être créés.

Considérons une version SmallTalk de FabriqueDeLabyrinthe, une version avec juste une opération de création prenant le type d’objet à créer en paramètre. En outre, la fabrique concrète garde enregistre les classes de produits qu’elle crée.

Tout d’abord, on écrit un équivalent de NouveauLabyrinthe en SmallTalk :

createMaze: aFactory  | room1 room2 aDoor |
 
room1 := (aFactory make: #room) number: 1.
 
room2 := (aFactory make: #room) number: 2.
 
aDoor := (aFactory make: #door) from: room1 to: room2.
 
room1 atSide: #north put: (aFactory make: #wall).
 
room1 atSide: #east put: aDoor.
 
room1 atSide: #south put: (aFactory make: #wall).
 
room1 atSide: #west put: (aFactory make: #wall).
 
room2 atSide: #north put: (aFactory make: #wall).
 
room2 atSide: #east put: (aFactory make: #wall).
 
room2 atSide: #south put: (aFactory make: #wall).
 
room2 atSide: #west put: aDoor.
 
^ Maze new addRoom: room1; addRoom: room2; yourself

Comme on l’a vu dans la section Implémentation, FabriqueDeLabyrinthe à seulement besoin d’une unique variable d’instance de CatalogueDePièce pour fournir un dictionnaire dont la clé est la classe de composant. Ainsi, voyons comment nous allons implémenter la méthode Construire :

make: partName
  ^ (partCatalog at: partName) new

Maintenant, on peut créer une FabriqueDeLabyrinthe et l’utiliser pour implémenter NouveauLabyrinthe. On vas créer la fabrique en utilisant une méthode NouvelleFabriqueDeLabyrinthe de la classe JeuDuLayrinthe.

createMazeFactory
  ^ (MazeFactory new
 
addPart: Wall named: #wall;
 
addPart: Room named: #room;
 
addPart: Door named: #door;
 
yourself)

Une FabriqueDeLabyrinthePiégé ou une FabriqueDeLabyrintheEnsorcelé est créée en associant différentes classes aux clés. Par exemple, une FabriqueDeLabyrintheEnsorcelé pourrait être crée comme ceci :

createMazeFactory
  ^ (MazeFactory new
 
addPart: Wall named: #wall;
 
addPart: EnchantedRoom named: #room;
 
addPart: DoorNeedingSpell named: #door;
 
yourself)

Utilisations connues

InterViews utilise le suffixe “Kit” pour les classes FabriqueAbstraite. Il définit les fabriques abstraites WidgetKit et DialogKit pour générer des objets d’interface utilisateur avec un style spécifique. InterViews inclus également un LayouKit qui génère différents objets de composition, dépendants de la mise en page désirée. Par exemple, une mise en page horizontale va demander des objets de composition différents selon l’orientation du document (porttrait ou paysage).

ET++ utilise la Fabrique Abstraite pour permettre la portabilité entre différents systèmes de fenêtrage (X Windows et SunView, par exemple). La classe abstraite de base WindowSystem définit l’interface pour créer des objets représentant les ressources d’un système de fenêtrage (MakeWindow, MakeFont, MakeColor, par exemple). Les classes concrètes dérivées implémentent les interfaces pour un système de fenêtrage spécifique. Lors de l’exécution, ET++ crée une instance d’une classe concrète dérivée de WindowSystem qui crée des objets concrets de ressources systèmes.

Voir Aussi

Les classes FabriqueAbstraite sont souvent implémentée avec le motif Fabrique, mais elles peuvent également être implémentée avec Prototype.

Une fabrique concrète est souvent un Singleton.

Aujourd’hui, je voulais juste vous faire part d’un nouveau contrat que j’ai : un site web !! Super, non ? Bon, c’est pas grand chose, juste un magazine gratuit local, ça fait 4 pages, avec un accueil, des archives, des partenaires et un formulaire de contact. Mais bon, c’est cool, ça faisait longtemps que j’avais pas bossé à mon compte… Et puis les dernières expériences s’étaient pas toutes super bien déroulées (des particuliers ou des associations, qui voulait des trucs fabuleux, mais si çà avait été gratuit ils auraitent préférés…). Alors que là, on sent que c’est du solide, plus réfléchi que la moyenne des clients.

Et puis, bon, faut dire que depuis que je fait du développement de site, je me suis vachement amélioré à force ! Pis je me suis mis au XHTML+CSS, avec des design de la mort… Enfin bref, c’est cool !

Je mettrais à jour le post quand le site sera fini… Histoire de mettre un petit lien !

/* Edité le 30/11/2007 à 09:54 */

Et voilà une miniature du site qui vous emmenera directement le voir :

Les motifs de Création permettent l’abstraction du processus d’instanciation. Ils aident à rendre le système indépendant de la manière dont les objets sont créés, assemblés et représentés. Une classe de motif de création utilise l’héritage afin de varier les classes devant être instanciées, tandis qu’un objet de motif de création va déléguer l’instanciation à un autre objet.

Les motifs de création gagnent en importance quand le système évolue afin de dépendre d’avantage de l’assemblage des objets plutôt que de l’héritage de classes. Durant cette transformation, on passe d’un code “en dur” avec un ensemble de comportements figés, vers un ensemble restreint de comportements fondamentaux qui peuvent être assemblés en de nombreux comportements plus complexes. Créer de cette manière des objets avec un comportement particulier demande plus qu’une simple instanciation de classe.

On retrouve deux thèmes réccurents dans ces motifs. Tout d’abord, ils encapsule la la visibilité de la classe concrète utilisée par le système. Ensuite, ils cachent la manière dont les instances de ces classes sont créées et mises ensemble. Tout ce que les systèmes connaissent des objets qu’ils utilisent, c’est leur interface telle qu’elle est définie par des classes abstraites. En conséquence, les motifs de création offrent une grande flexibilitésur ce qui est créé, qui le crée, comment c’est créé et quand. Ils permettent de configurer un système avec des objets “de production” variant énormément en termes de structures et de fonctionnalités. La configuration peut être statique (définie à la compilation) ou dynamique (au chargement).

Parfois, les motifs de création entrent en compétition. Par exemple, on trouve des cas où les motifs Prototype ou Fabrique Abstraite (Abstract Factory) seraient tous les deux utiles. À d’autres moments, ils sont complémentaires : Monteur (Builder) peut utiliser d’autres motifs pour implémenter quel composant doit être créé. Prototype peut utiliser Singleton dans son implémentation.

Comme les motifs de création sont très proches les uns des autres, nous allons étudier les cinq ensemble afin de souligner leurs points communs et leurs différences. Nous allons également utiliser un exemple commun (construire un labyrinthe pour les besoins d’un jeu) afin d’illustrer leurs implémentation. Le labyrinthe et le jeu vont légèrement varier d’un motif à l’autre. Parfois, le jeu consistera simplement à trouver son chemin dans le labyrinthe ; dans ce cas le joueur n’aura probablement qu’une vue restreinte du labyrinthe. D’autres fois, le labyrinthe contiendra des énigmes à résoudre et des dangers à éviter, et ces jeux fourniront une carte de la partie du labyrinthe ayant été explorée.

On ignorera de nombreux détails sur ce qui peut être dans le labyrinthe, ou si le jeu a un ou plusieurs joueurs. Au lieu de cela, nous nous focaliserons sur la manière dont le labyrinthe est créé. On définit un labyrinthe comme un ensemble de pièces. Une pièce connaît son voisinage ; ses voisins peuvent être une autre pièce, un mur, ou une porte vers une autre pièce.

Les classes Pièce, Porte et Mur définissent les composants du labyrinthe utilisés dans tous nos exemples. Nous ne définirons que les parties de ces classes importantes pour créer un labyrinthe. Nous ignorerons les joueurs, les méthodes d’affichage et d’exploration du labyrinthe, et d’autres fonctionnalités importantes qui ne sont pas essentielles pour construire le labyrinthe.

Le schéma suivant montre les relations entre ces classes :

Chaque pièce a quatre côtés. Nous utiliserons une énumération appelée Direction pour spécifier les faces nord, sud, est et ouest d’une pièce :

Enum Direction
 
  Nord
 
  Sud
 
  Est
 
  Ouest
 
End Enum

La classe ComposantLabyrinthe est la classe abstraite commune à tous les composants d’un labyrinthe. Pour simplifier l’exemple, ComposantLabyrinthe ne définit qu’une méthode, Entrer. Sons sens dépend de ce dans quoi vous entrez. Si vous entrez dans une pièce, votre localisation change. Si vous essayez d’entrer dans une portes, deux solutions : soit la porte est ouverte et vous changez de pièce, soit la porte est fermée et vous vous cognez le nez.

MustInherit Class ComposantLabyrinthe
 
  Public MustOverride Sub Entrer()
 
End Class

Entrer fournit une simple base pour des actions de jeu plus sophistiquées. Par exemple, si vous êtes dans une pièce et que vous dites “Aller à l’Est”, le jeu peut déterminer simplement quel ComposantLabyrinthe est positionné à l’est, et appeler sa méthode Entrer. La méthode Entrer spécifique à la sous-classe va s’occuper de savoir si vous allez changer de pièce ou si vous allez avoir mal au nez. Dans un vrai jeu, Entrer pourrait prendre en argument l’objet Joueur en train de bouger. Pièce est la sous-classe concrète de ComposantLabyrinthe qui définit les relations-clés entre les différents composants du labyrinthe. Elle maintient les références aux autres composants et enregistre un numéro de pièce. Le numéro va identifier les pièces du labyrinthe.

Class Pièce
 
    Inherits ComposantLabyrinthe    Private _cotes(4) As ComposantLabyrinthe
 
    Private _numero As Integer
 
Public Property Cote(ByVal dir As Direction) As ComposantLabyrinthe
 
        Get
 
            Return _cotes(dir)
 
        End Get
 
        Set(ByVal value As ComposantLabyrinthe)
 
            _cotes(dir) = value
 
        End Set
 
    End Property
 
Public ReadOnly Property Numero() As Integer
 
        Get
 
            Return _numero
 
        End Get
 
    End Property
 
Public Sub New(ByVal numero As Integer)
 
        _numero = numero
 
    End Sub
 
Public Overrides Sub Entrer()
 
        '...
 
    End Sub
 
End Class

Les classes suivantes représentent les murs et les portes.

Class Mur
 
    Inherits ComposantLabyrinthe    Public Sub New()
 
        '...
 
    End Sub
 
Public Overrides Sub Entrer()
 
        '...
 
    End Sub
 
End Class
 
Class Porte
 
    Inherits ComposantLabyrinthe
 
Private _piece1 As Pièce
 
    Private _piece2 As Pièce
 
    Private _ouverte As Boolean
 
Public Sub New(ByVal p1 As Pièce, ByVal p2 As Pièce)
 
        _piece1 = p1
 
        _piece2 = p2
 
        _ouverte = False
 
    End Sub
 
Public Function AutreCote(ByVal p As Pièce) As Pièce
 
        If p Is _piece1 Then
 
            Return _piece2
 
        ElseIf p Is _piece2 Then
 
            Return _piece1
 
        End If
 
        Return Nothing
 
    End Function
 
Public Overrides Sub Entrer()
 
        '...
 
    End Sub
 
End Class

On a besoin de connaître plus qu’une simple partie du labyrinthe. On définit en plus une classe Labyrinthe qui représente une collection de pièces. Labyrinthe peut aussi trouver une pièce donnée à partir de son numéro, en utilisant la méthode PieceNo.

Class Labyrinthe
 
    Private _pieces() As Pièce    Public Sub New()
 
        '...
 
    End Sub
 
Public Sub AjouterPiece(ByVal p As Pièce)
 
        '...
 
    End Sub
 
Public Function PieceNo(ByVal n As Integer) As Pièce
 
        For Each p As Pièce In _pieces
 
            If p.Numero = n Then
 
                Return p
 
            End If
 
        Next p
 
        Return Nothing
 
    End Function
 
End Class

PieceNo peut faire une recherche par dictionnaire, table de hashage, ou un simple tableau comme ci-dessus. On ne se préoccupe pas de ces détails ici. Au lieu de ça, nous allons nous focaliser sur la manière de spécifier les composants d’un objet Labyrinthe.

Une autre classe à définir va être JeuDuLabyrinthe, qui va créer le labyrinthe. Une manière directe de créer le labyrinthe va être de spécifier une série d’opérations pour ajouter des composants à un labyrinthe et les connecter entre eux. Par exemple, la function suivante va créer un labyrinthe composé de deux pièces avec une porte entre les deux :

Public Function NouveauLabyrinthe() as Labyrinthe
 
    Dim oLabyrinthe as Labyrinthe = New Labyrinthe()
 
    Dim oPiece1 = New Pièce(1)
 
    Dim oPiece2 = New Pièce(2)
 
    Dim oPorte = New Porte(oPiece1, oPiece2)    oLabyrinthe.AjouterPiece(oPiece1)
 
    oLabyrinthe.AjouterPiece(oPiece2)
 
oPiece1.Cote(Nord) = New Mur()
 
    oPiece1.Cote(Sud) = New Mur()
 
    oPiece1.Cote(Est) = oPorte
 
    oPiece1.Cote(Ouest) = New Mur()
 
oPiece2.Cote(Nord) = New Mur()
 
    oPiece2.Cote(Sud) = New Mur()
 
    oPiece2.Cote(Est) = New Mur()
 
    oPiece2.Cote(Ouest) = oPorte
 
Return oLabyrinthe
 
End Function

Cette fonction est quelque peu compliquée si l’on considère qu’elle ne fait que créer un labyrinthe à deux pièces. On pourrait évidemment simplifier cela. Par exemple, le constructeur de Pièce pourrait initialiser les côtés par un mur dès le départ. Mais ça ne ferait que déplacer le code ailleurs. Le vrai problème avec cette fonction ne vient pas de sa taille mais plutôt de son manque de flexibilité. On code en dur le schéma du labyrinthe. Changer de schéma signifie changer de fonction, s