Maison >Java >javaDidacticiel >Introduction au modèle d'usine dans les modèles de conception Java (exemple de code)

Introduction au modèle d'usine dans les modèles de conception Java (exemple de code)

不言original: 2018-09-12 15:54:241902parcourir

Cet article vous présente une introduction au modèle d'usine dans les modèles de conception Java (exemples de code), qui a une certaine valeur de référence. Les amis dans le besoin peuvent s'y référer. J'espère qu'il vous sera utile.

Préface

Dans l'article précédent, nous avons découvert le modèle singleton et présenté plusieurs méthodes de création du modèle singleton ainsi que la méthode optimale. Cet article présente le modèle d'usine dans les modèles de conception, qui est principalement divisé en modèle d'usine simple, méthode d'usine et modèle d'usine abstrait.

Modèle d'usine simple

Le modèle d'usine simple est un modèle de création, également appelé modèle de méthode d'usine statique. Le modèle d'usine simple utilise un objet d'usine pour déterminer quelle instance de classe de produits créer. L'appel doit uniquement indiquer à la classe d'usine le type requis, et la classe d'usine renverra la sous-classe de l'usine de classe de produit requise. On peut dire que c'est le modèle le plus simple parmi les modèles d'usine.

Par exemple, nous jouons souvent à des jeux sur l'ordinateur. Il nous suffit de dire à l'ordinateur à quel jeu nous voulons jouer, et l'ordinateur ouvrira le jeu. Nous n'avons pas besoin de nous soucier du fonctionnement du jeu. .
Nous pouvons expliquer en conséquence dans le code suivant.

Nous créons d'abord une interface de classe générale de jeu, comprenant une méthode pour jouer au jeu ; puis les classes de jeu respectives héritent de cette classe et implémentent les méthodes de cette classe, et enfin créons une classe d'ingénierie selon différents jeux. Créez des objets.
Ensuite, le code implémenté est le suivant :

Exemple de code :

    private static final String LOL="LOL"; 
    private static final String DNF="DNF"; 
    
    public static void main(String[] args) {
        Game game= ComputerFactory.playGame(LOL);
        Game game2= ComputerFactory.playGame(DNF);
        game.play();
        game2.play();
    }
}

interface Game{
    void play();
}

class LOL implements Game{
    @Override
    public void play() {
        System.out.println("正在玩LOL...");
    }   
}

class DNF implements Game{
    @Override
    public void play() {
        System.out.println("正在玩DNF...");
    }   
}


class ComputerFactory{
    private static final String LOL="LOL"; 
    private static final String DNF="DNF"; 
     public static Game playGame(String game){
         if(LOL.equalsIgnoreCase(game)){
             return new LOL();
         }else if(DNF.equalsIgnoreCase(game)){
             return new DNF();
         }
         return null;
     }

Résultat de sortie :

正在玩LOL...
正在玩DNF...

Après avoir utilisé le modèle d'usine simple pour implémenter cette fonction, nous constaterons que nous implémentons l'instanciation de la classe de jeu dans la classe d'usine, cachant les détails de la création d'objets, et n'avons pas besoin de savoir comment jouer, seulement besoin de savoir comment appeler la classe Factory fera l'affaire. Et il est pratique de changer, car il vous suffit de modifier la valeur de type transmise par la classe d'usine.
Mais nous avons également trouvé un problème. Si nous devons ajouter une nouvelle classe de jeu, nous devons définir une nouvelle interface, puis ajouter une branche de jugement à la classe d'usine. Si c'est une petite quantité, ce n'est pas grave, mais s'il s'agit d'un montant important, ce sera plus gênant, et cela viole également le principe ouvert-fermé.

Modèle de méthode d'usine

Le modèle de méthode d'usine est l'un des modèles de conception les plus couramment utilisés en Java et est un modèle de création. Définissez une interface pour créer des objets et laissez ses sous-classes décider quelle classe d'usine instancier. Le modèle d'usine retarde le processus de création jusqu'aux sous-classes.

Dans le modèle d'usine simple, nous avons constaté que lors de l'ajout d'une sous-classe, nous devons également ajouter une branche de jugement à la classe d'usine, ce qui viole le principe ouvert-fermé. Le modèle de méthode d'usine résout principalement ce problème.

L'exemple de jeu ci-dessus est toujours utilisé ici, sauf que chaque jeu ici est implémenté par sa propre classe de fabrique de jeux. La principale différence est qu'il existe plusieurs classes d'usine au lieu d'une, ce qui réduit le degré de couplage. Si vous ajoutez une nouvelle classe de jeu, il vous suffit d'ajouter une classe d'usine, et le principe ouvert-fermé est parfaitement suivi.

Après avoir modifié le code ci-dessus, le code correspondant est implémenté comme suit :

Exemple de code :

    private static final String LOL="LOL"; 
    private static final String DNF="DNF"; 
    private static final String WOW="WOW"; 

    public static void main(String[] args) {

        Game game3=new LOLFactory().playGame(LOL);
        Game game4=new DNFFactory().playGame(DNF);
        Game game5=new WOWFactory().playGame(WOW);
        game3.play();
        game4.play();
        game5.play();       
    }
    
interface Game{
    void play();
}


class LOL implements Game{
    @Override
    public void play() {
        System.out.println("正在玩LOL...");
    }   
}

class DNF implements Game{
    @Override
    public void play() {
        System.out.println("正在玩DNF...");
    }   
}

class WOW  implements Game{
    @Override
    public void play() {
        System.out.println("正在玩WOW...");
    }   
}


interface ComputerFactory2{
    Game playGame(String game);
}

class LOLFactory implements ComputerFactory2{
    @Override
    public Game playGame(String game) {
        return new LOL();
    }
}

class DNFFactory implements ComputerFactory2{
    @Override
    public Game playGame(String game) {
        return new DNF();
    }
}

class WOWFactory implements ComputerFactory2{
    @Override
    public Game playGame(String game) {
        return new WOW();
    }
}

Résultat de sortie :

正在玩LOL...
正在玩DNF...
正在玩WOW...

Vous pouvez voir qu'après avoir utilisé le modèle de méthode d'usine, notre code devient plus clair et l'évolutivité devient plus élevée. Si nous voulons ajouter un produit, il nous suffit d'étendre une classe d'usine. Mais ce qui s'ensuit est une complexité accrue du système. Chaque fois qu'un produit est ajouté, une classe concrète et une classe d'usine d'implémentation d'objet doivent être ajoutées.
Vous devez donc faire attention à savoir si vous devez utiliser ce mode.
Un cas d'utilisation classique pour l'utilisation de ce modèle est le célèbre framework hibernate pour sélectionner un dialecte de base de données. Mais si vous créez simplement un objet directement, vous n'avez pas besoin de l'utiliser, cela augmentera la complexité du système.

Modèle d'usine abstrait

Le modèle d'usine abstrait consiste à créer d'autres usines autour d'une super usine. La Gigafactory est également connue comme l’usine des autres usines. Ce type de modèle de conception est un modèle de création qui offre une manière optimale de créer des objets. C'est-à-dire fournir une interface permettant de créer une série d'objets liés ou interdépendants sans spécifier leurs classes spécifiques.

Le modèle d'usine abstrait est plus complexe et difficile à comprendre que le modèle de méthode d'usine, mais il est plus facile à étendre.
Le modèle d'usine abstrait regroupe les sous-catégories de produits du même type dans une seule catégorie, leur permet d'hériter de la même sous-catégorie abstraite, puis les traite comme un groupe, puis regroupe plusieurs groupes dans une famille.
Par exemple, en jouant toujours aux jeux mentionnés ci-dessus, nous pouvons considérer LOL et WOW comme des jeux de type PVP, ou nous pouvons considérer DNF et WOW sont traités comme des jeux de type PVE.

Ensuite, le code modifié correspondant est le suivant :

Exemple de code :

    private static final String LOL="LOL"; 
    private static final String DNF="DNF"; 
    private static final String WOW="WOW"; 
    
    public static void main(String[] args) {

        ComputerFactory3 cf3=new PVPFactory();
        cf3.playGame().play();
        cf3.playGame2().play();
        ComputerFactory3 cf4=new PVEFactory();
        cf4.playGame().play();
        cf4.playGame2().play();         
    }       
}


interface Game{
    void play();
}


class LOL implements Game{
    @Override
    public void play() {
        System.out.println("正在玩LOL...");
    }   
}

class DNF implements Game{
    @Override
    public void play() {
        System.out.println("正在玩DNF...");
    }   
}

class WOW  implements Game{
    @Override
    public void play() {
        System.out.println("正在玩WOW...");
    }   
}


interface ComputerFactory3{
     Game playGame();
     Game playGame2();
}

class PVPFactory implements ComputerFactory3{

    @Override
    public Game playGame() {
        return new LOL();
    }

    @Override
    public Game playGame2() {
        return new WOW();
    }   
}

class PVEFactory implements ComputerFactory3{

    @Override
    public Game playGame() {
        return new DNF();
    }

    @Override
    public Game playGame2() {
        return new WOW();
    }
    
}

Résultat de sortie :

正在玩LOL...
正在玩WOW...
正在玩DNF...
正在玩WOW...

在抽象工厂模式中，可以在不需要知道产品是怎么样的，只需知道是哪个工厂类就行了。我们也可以根据子类的共同的特性而将它们设计在一起，组成一个相同类型组，可以很方便的直接调用。但是相对的，产品族比较难以扩展，增加一个产品，需要增加相应的接口和实现类。例如某个品牌的手机，有不同系列，每个系列有不同的型号，如果只是增加型号的话，比较容易，但是相对的，增加某个系列就比较麻烦了。
所以我们在使用抽象工厂模式，也需要相应的结合实际场景来使用。

Articles Liés

Voir plus