Design pattern Fabrique (Factory Method) en Java : jeu de stratégie

Implémentation en Java du design pattern Fabrique lors du développement d'un jeu de stratégie.

Description du problème

L'idée est de développer les bases d'un jeu de stratégie en temps réel (RTS pour les gamers). Dans ce type de jeu, la plupart des unités permettent de faire la guerre aux autres joueurs. Le vainqueur sera le dernier joueur disposant encore d'unités sur la carte. Généralement, les unités sont construites dans des bâtiments (usines, casernes...) grâce à des ressources (minerais, bois...) qu'il faut prélever sur la carte.

Pour cela, nous allons définir une classe abstraite Unite disposant d'un nom, d'un coût de construction, d'une précision d'attaque, d'une faculté d'esquive...

// Classe abstraite dont toutes les unités du jeu hériteront.
public abstract class Unite 
{
    protected String nom;// Nom de l'unité.
    protected int coutConstruction;// Coût de construction de l'unité.
    protected int precisionAttaque;// Précision de l'attaque de l'unité.
    protected int esquiveDefense;// Faculté d'esquiver une attaque de l'unité.
    protected ArrayList equipements;// Tableau des équipements de l'unité.
     
    // Méthode qui consomme les ressources pour créer une unité.
    public void consommerRessource()
    {
        System.out.println("Consomme "+this.coutConstruction+" ressources pour la création de l'unité.");
    }
     
    // Méthode abstraite qui permet d'équiper l'unité.
    public abstract void equiper();
     
    // Méthode générique pour l'affichage de l'unité.
    public String toString()
    {
        String str = "Nom : "+this.nom+"\n";
        str += "Coût de construction : "+this.coutConstruction+"\n";
        str += "Précision d'attaque : "+this.precisionAttaque+"\n";
        str += "Esquive en défense : "+this.esquiveDefense+"\n";
        str += "Equipements : ";
        for(int i=0; i<this.equipements.size(); i++)
        {
            str += this.equipements.get(i)+" ";
        }
        return str;
    }
}

Toutes les unités de notre jeu vont hériter de cette classe comme par exemple la classe SoldatHumain et CommandantHumain en ayant chacune leurs propres spécificités (le commandant est plus coûteux que le soldat mais dispose d'une précision d'attaque supérieure).

// Classe représentant un soldat humain.
public class SoldatHumain extends Unite 
{
    // Constructeur pour un soldat humain.
    public SoldatHumain()
    {
        this.nom = "Fantassin";
        this.coutConstruction = 5;
        this.precisionAttaque = 1;
        this.esquiveDefense = 2;
        this.equipements = new ArrayList();
    }
     
    // Equiper un soldat humain.
    public void equiper()
    {
        this.equipements.add("Pistoler");
        this.equipements.add("Bouclier");
        System.out.println("Equipement d'un soldat humain (Pistoler, Bouclier).");
    }
}
 
// Classe représentant un commandant humain.
public class CommandantHumain extends Unite 
{
    // Constructeur pour un commandant humain.
    public CommandantHumain()
    {
        this.nom = "Lieutenant";
        this.coutConstruction = 14;
        this.precisionAttaque = 5;
        this.esquiveDefense = 2;
        this.equipements = new ArrayList();
    }
     
    // Equiper un commandant humain.
    public void equiper()
    {
        this.equipements.add("Uzi");
        this.equipements.add("Bouclier");
        System.out.println("Equipement d'un commandant humain (Uzi, Bouclier).");
    }
}

Une classe Usine va permettre de créer ces unités grâce à la méthode formerUnite(TypeUnite). La première idée qui vient à l'esprit pour implémenter cette méthode est de tester le type d'unité souhaité passé en paramètre (via une succession de if ou mieux un switch) et de créer un objet correspondant à l'unité demandée (par exemple : new SoldatHumain()).

Ce code va fonctionner mais on remarque qu'en utilisant l'opérateur new, on vient de déclarer des types concrets dans la classe Usine ce qui a pour conséquence de fortement coupler la classe Usine aux classes SoldatHumain et CommandantHumain. Est-ce un mal, car il faudra bien créer des objets concrets et l'opérateur new est conçu pour cela ? En effet, il n'est pas envisageable de développer un programme orienté objet en Java sans utiliser l'opérateur new et donc d'utiliser des types concrets. Cependant dans ce cas précis, on peut facilement prévoir que cette portion du code va être amené à évoluer lors de l'ajout de nouvelles unités. De plus, si plusieurs bâtiments différents permettent de créer des unités, les modifications devront être reporté dans plusieurs endroits du jeu. Cela va donc vite devenir de plus en plus fastidieux d'ajouter des unités et des bâtiments et surtout source d'erreurs en étant obligé de modifier le code existant.

Implémentation d'un début de solution avec une Simple Fabrique

Pour répondre à cette problématique on va implémenter une simple fabrique, qui pour rappel est une bonne pratique de conception mais pas un design pattern a proprement parlé. Le principe est de regrouper l'instanciation des unités dans une seule classe, ici SimpleFabrique, afin d'éviter la duplication de cette portion du code vouée aux évolutions.

// Classe permettant de fabriquer une unité.
public class SimpleFabrique 
{
    // La création d'une unité en fonction de son type est encapsulée dans la fabrique.
    public Unite creerUnite(TypeUnite type)
    {
        Unite unite = null;;
        switch(type)
        {
            case SOLDAT:unite = new SoldatHumain();break;
            case COMMANDANT:unite = new CommandantHumain();break;
        }
        return unite;
    }
}
 
// Enumération des types d'unités.
public enum TypeUnite 
{
    SOLDAT,
    COMMANDANT
}

La classe SimpleFabrique a donc pour seule responsabilité d'instancier l'unité correspondant au type passé en paramètre de sa méthode creerUnite(TypeUnite). Au passage on peut noter l'utilisation d'une énumération en java pour ce paramètre qui est bien plus sûr qu'une simple chaîne de caractères (et surtout qui est utilisable avec l'instruction switch).

// Classe usine qui représente un bâtiment capable de construire des unités.
public class Usine 
{
    private SimpleFabrique simpleFabrique;// Attribut contenant la fabrique simple.
     
    // Le constructeur permet de sélectionner la fabrique à utiliser.
    public Usine()
    {
        this.simpleFabrique = new SimpleFabrique();
    }
     
    // Méthode qui permet de construire l'ensemble des unités.
    public Unite formerUnite(TypeUnite type)
    {
        Unite unite = this.simpleFabrique.creerUnite(type);
        unite.consommerRessource();
        unite.equiper();
        return unite;
    }
}

La classe Usine conserve un objet SimpleFabrique dans un attribut initialisé dans son constructeur. La méthode formerUnite(TypeUnite) n'instancie pas directement des unités mais délègue cette tâche à l'objet SimpleFabrique. On remarque alors que la classe Usine est maintenant couplée fortement à la seule classe SimpleFabrique via une relation de composition.

Si une nouvelle classe correspondant à un autre bâtiment est ajoutée il suffira d'utiliser la simple fabrique pour instancier les unités. Quand à l'ajout d'unités, il ne nécessite maintenant que la modification de la seule classe SimpleFabrique.

// Classe principale du projet.
public class Main 
{
    // Méthode principale.
    public static void main(String[] args) 
    {
        Usine usine = new Usine();
        Unite unite = usine.formerUnite(TypeUnite.SOLDAT);
        System.out.println(unite);
    }
}

La classe Main correspond à la classe principale de notre jeu. Elle va nous permettre de créer une usine afin d'y former un soldat.

Consomme 5 ressources pour la création de l'unité.
Equipement d'un soldat humain (Pistoler, Bouclier).
Nom : Fantassin
Coût de construction : 5
Précision d'attaque : 1
Esquive en défense : 2
Equipements : Pistoler Bouclier

Pour notre grand bonheur le jeu fonctionne et le résultat correspond à nos attentes.

Cette bonne pratique, nous a donc permis de répondre de façon élégante à la problématique rencontrée. Mais notre jeu va devoir se complexifier car les retours des bêta-testeurs indiquent que celui-ci manque de diversité. Il serait intéressant de créer plusieurs races ayant chacune des unités (Soldat, Commandant...) et des bâtiments. Idéalement il faudrait que des développeurs externes au projet puissent proposer de nouvelles races sous forme d'addons sans toucher aux fichiers de l'application (afin de maîtriser la qualité du jeu et de rendre possible l'utilisation de plusieurs addons simultanément).

Ci-dessous, le diagramme de classe correspondant à ces nouveaux besoins et qui utilise le design pattern Fabrique afin de répondre aux contraintes évoquées.

Implémentation avec le design pattern Fabrique

Aucun changement concernant les classes Unite, SoldatHumain et CommandantHumain. Cependant, on note l'ajout de deux nouvelles classes correspondant aux soldats et aux commandants extraterrestres.

// Classe représentant un soldat extraterrestre.
public class SoldatExtraterrestre extends Unite 
{
    // Constructeur pour un soldat extraterrestre.
    public SoldatExtraterrestre()
    {
        this.nom = "Alien";
        this.coutConstruction = 6;
        this.precisionAttaque = 2;
        this.esquiveDefense = 1;
        this.equipements = new ArrayList();
    }
     
    // Equiper un soldat extraterrestre.
    public void equiper()
    {
        this.equipements.add("Acide");
        this.equipements.add("Peau");
        System.out.println("Equipement d'un soldat extraterrestre (Acide, Peau).");
    }
}
 
// Classe représentant un commandant extraterrestre.
public class CommandantExtraterrestre extends Unite 
{
    // Constructeur pour un commandant extraterrestre.
    public CommandantExtraterrestre()
    {
        this.nom = "Prédateur";
        this.coutConstruction = 10;
        this.precisionAttaque = 3;
        this.esquiveDefense = 3;
        this.equipements = new ArrayList();
    }
     
    // Equiper un commandant extraterrestre.
    public void equiper()
    {
        this.equipements.add("Mitraillette à plasma");
        this.equipements.add("Peau");
        System.out.println("Equipement d'un commandant extraterrestre (Mitraillette à plasma, Peau).");
    }
}

L'implémentation de ces classes n'offre aucune surprise par rapport aux classes SoldatHumain et CommandantHumain. Seules les caractéristiques des unités (coût de construction, précision d'attaque...) changent. Les modifications les plus intéressantes se situent dans les classes représentant les usines.

// Usine abstraite qui sert de base aux usines concrètes.
public abstract class Usine 
{
    // Méthode qui permet de former les unités.
    public Unite formerUnite(TypeUnite type)
    {
        Unite unite = this.creerUnite(type);
        unite.consommerRessource();
        unite.equiper();
        return unite;
    }
     
    // La création d'une unité est déléguée aux sous classes.
    public abstract Unite creerUnite(TypeUnite type);
}

La classe Usine est maintenant abstraite, car elle déclare une méthode creerUnite(TypeUnite) abstraite. On conserve la méthode formerUnite(TypeUnite) mais celle-ci fait maintenant appel à sa méthode creerUnite(TypeUnite) déclarée abstraite pour instancier les unités.

La classe Usine étant maintenant abstraite, elle ne permet plus directement de créer et former des unités, il va falloir pour cela créer des sous-classes. L'objectif de l'implémentation de la classe Usine étant de déléguer l'instanciation des unités à ses sous-classes, ce qui correspond exactement à la description du design pattern Fabrique. A noter que la classe Usine conserve toute de même la responsabilité de la formation des unités pour assurer un jeu cohérent (pas question de créer des unités sans consommer des ressources ou sans les équiper). Pour plus de sécurité, on aurait pu déclarer la méthode formerUnite(TypeUnite) comme « final » afin que ses sous classes ne puissent pas la redéfinir.

// Usine humaine.
public class UsineHumain extends Usine
{
    // Méthode qui permet de créer des unités humaines.
    public Unite creerUnite(TypeUnite type)
    {
        Unite unite = null;;
        switch(type)
        {
            case SOLDAT:unite = new SoldatHumain();break;
            case COMMANDANT:unite = new CommandantHumain();break;
        }
        return unite;
    }
}
 
// Usine extraterrestre.
public class UsineExtraterrestre extends Usine
{
    // Méthode qui permet de créer des unités extraterrestres.
    public Unite creerUnite(TypeUnite type)
    {
        Unite unite = null;;
        switch(type)
        {
            case SOLDAT:unite = new SoldatExtraterrestre();break;
            case COMMANDANT:unite = new CommandantExtraterrestre();break;
        }
        return unite;
    }
}

Les classes UsineHumain et UsineExtraterrestre héritent simplement de la classe Usine et implémentent la méthode creerUnite(TypeUnite) permettant l'instanciation des unités du jeu.

// Classe principale du projet.
public class Main 
{
    // Méthode principale.
    public static void main(String[] args) 
    {
        Usine usineExtraterrestre = new UsineExtraterrestre();
        Unite unite = usineExtraterrestre.formerUnite(TypeUnite.SOLDAT);
        System.out.println(unite);
    }
 
}

On modifie la précédente classe Main afin de tester la création d'un soldat extraterrestre grâce à la nouvelle usine d'extraterrestres.

Consomme 6 ressources pour la création de l'unité.
Equipement d'un soldat extraterrestre (Acide, Peau).
Nom : Alien
Coût de construction : 6
Précision d'attaque : 2
Esquive en défense : 1
Equipements : Acide Peau 

Le résultat obtenu en console est une fois de plus à la hauteur de nos attentes. On obtient bien un soldat extraterrestre après avoir consommé les ressources nécessaires à sa construction puis l'avoir équipé.

Conclusion

Grâce au design pattern Fabrique l'ajout d'une nouvelle race dans notre jeu ne nécessite pas de modifier le code existant (exceptée la classe principale Main). En effet, il suffit de créer les classes correspondantes aux unités (qui hériteront de la classe Unite) puis de créer l'usine correspondante (voir même les usines). Seul l'ajout d'une unité nécessite de modifier les classes usines concrètes permettant de les instancier. Mais cela semble tout à fait logique car si aucune usine ne permet de créer cette unité il ne sera pas possible de la rencontrer dans le jeu.

La pattern Fabrique répond à la problématique courante des développeurs d'encapsuler la création des objets. Les principales raisons sont de découpler une partie du code des classes concrètes que l'on doit instancier ou de permettre facilement d'ajouter des classes concrètes ultérieurement. A noter que si votre besoin correspond à la création d'une famille de produits, il existe le design pattern Fabrique Abstraite (son cousin) qui y répond parfaitement.

Code source

Design-patterns.fr est un site internet collaboratif qui a pour objectif de promouvoir les bonnes pratiques de conceptions des applications.

L’accent est mis sur les Design Patterns (patrons de conception) qui décrivent des solutions à des problèmes récurrents d’architecture et de conceptions des logiciels.

Pour chaque Design Pattern, on trouve un article "thèorique" l'expliquant puis un ou plusieurs exemples originaux d'implémentations dans différents langages de programmation.