Einführung in Factory Pattern in Java Design Patterns (Codebeispiel)-javaLernprogramm-php.cn

Dieser Artikel bietet Ihnen eine Einführung in das Factory-Muster in Java-Designmustern (Codebeispiele), die für Freunde in Not hilfreich sein können.

Vorwort

Im vorherigen Artikel haben wir etwas über das Singleton-Muster gelernt und verschiedene Methoden zum Erstellen des Singleton-Musters sowie die optimale Methode vorgestellt. In diesem Artikel wird das Fabrikmuster in Entwurfsmustern vorgestellt, das hauptsächlich in einfache Fabrikmuster, Fabrikmethoden und abstrakte Fabrikmuster unterteilt ist.

Einfaches Factory-Muster

Das einfache Factory-Muster ist ein Erstellungsmuster, das auch als statisches Factory-Methodenmuster bezeichnet wird. Das einfache Factory-Muster verwendet ein Factory-Objekt, um zu entscheiden, welche Produktklasseninstanz erstellt werden soll. Der Aufruf muss der Factory-Klasse lediglich den erforderlichen Typ mitteilen, und die Factory-Klasse gibt die erforderliche Unterklasse der Produktklasse Factory zurück. Man kann sagen, dass es das einfachste unter den Fabrikmustern ist.

Zum Beispiel spielen wir oft Spiele auf dem Computer. Wir müssen dem Computer nur sagen, welches Spiel wir spielen möchten, und der Computer öffnet das Spiel. Es ist uns egal, wie das Spiel funktioniert .
Das können wir im folgenden Code entsprechend erklären.

Wir erstellen zunächst eine allgemeine Spielklassenschnittstelle, einschließlich einer Methode zum Spielen des Spiels, dann erben die jeweiligen Spielklassen diese Klasse und implementieren die Methoden dieser Klasse und erstellen schließlich eine technische Klasse für verschiedene Spiele. Objekte erstellen.
Dann lautet der implementierte Code wie folgt:

Codebeispiel:

    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;
     }

Nach dem Login kopieren

Ausgabeergebnis:

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

Nach dem Login kopieren

Wir Sie verwenden Nachdem Sie diese Funktion im einfachen Factory-Modus implementiert haben, werden Sie feststellen, dass wir die Instanziierung der Spielklasse in die Factory-Klasse einfügen und die Details der Objekterstellung verbergen. Sie müssen nicht wissen, wie man spielt, sondern nur Sie Ich muss wissen, wie man die Factory-Klasse aufruft. Und der Wechsel ist bequem, da Sie nur den von der Factory-Klasse übergebenen Typwert ändern müssen.
Aber wir haben auch ein Problem gefunden. Wenn wir eine neue Spielklasse hinzufügen müssen, müssen wir eine neue Schnittstelle definieren und dann einen Beurteilungszweig zur Fabrikklasse hinzufügen. aber wenn es eine große Menge ist, wird es problematischer, und dies verstößt auch gegen das Offen-Geschlossen-Prinzip.

Factory-Methodenmuster

Factory-Methodenmuster ist eines der am häufigsten verwendeten Entwurfsmuster in Java und ein Erstellungsmuster. Definieren Sie eine Schnittstelle zum Erstellen von Objekten und lassen Sie ihre Unterklassen entscheiden, welche Factory-Klasse instanziiert werden soll. Das Factory-Muster verzögert den Erstellungsprozess bis zu den Unterklassen.

Im einfachen Fabrikmuster haben wir festgestellt, dass wir beim Hinzufügen einer Unterklasse auch einen Beurteilungszweig zur Fabrikklasse hinzufügen müssen, was gegen das Offen-Geschlossen-Prinzip verstößt. Das Factory-Methodenmuster löst dieses Problem hauptsächlich.

Das obige Beispiel zum Spielen von Spielen wird hier immer noch verwendet, mit der Ausnahme, dass jedes Spiel hier durch eine eigene Game-Factory-Klasse implementiert wird. Der Hauptunterschied besteht darin, dass es mehrere Factory-Klassen anstelle einer gibt, was den Kopplungsgrad verringert. Wenn Sie eine neue Spielklasse hinzufügen, müssen Sie nur eine Fabrikklasse hinzufügen, und das Offen-Geschlossen-Prinzip wird perfekt befolgt.

Nach der Änderung des obigen Codes wird der entsprechende Code wie folgt implementiert:

Codebeispiel:

    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();
    }
}

Nach dem Login kopieren

Ausgabeergebnis:

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

Nach dem Login kopieren

Sie können sehen, dass unser Code nach Verwendung des Factory-Methodenmusters klarer und die Skalierbarkeit höher wird. Wenn wir ein Produkt hinzufügen möchten, müssen wir nur eine Factory-Klasse erweitern. Was jedoch folgt, ist eine Zunahme der Komplexität im System. Jedes Mal, wenn ein Produkt hinzugefügt wird, müssen eine konkrete Klasse und eine Objektimplementierungs-Factory-Klasse hinzugefügt werden.
Sie müssen also darauf achten, ob Sie diesen Modus verwenden möchten.
Ein klassischer Anwendungsfall für die Verwendung dieses Musters ist das berühmte Hibernate-Framework bei der Auswahl eines Datenbankdialekts. Aber wenn Sie einfach ein neues Objekt verwenden, müssen Sie es nicht verwenden. Wenn Sie es verwenden, erhöht sich die Komplexität des Systems.

Abstraktes Fabrikmuster

Abstraktes Fabrikmuster besteht darin, weitere Fabriken rund um eine Superfabrik zu errichten. Die Gigafactory wird auch als Fabrik der anderen Fabriken bezeichnet. Bei dieser Art von Entwurfsmuster handelt es sich um ein Erstellungsmuster, das eine optimale Möglichkeit zum Erstellen von Objekten bietet. Das heißt, es wird eine Schnittstelle zum Erstellen einer Reihe verwandter oder voneinander abhängiger Objekte bereitgestellt, ohne deren spezifische Klassen anzugeben.

Das abstrakte Factory-Muster ist komplexer und schwieriger zu verstehen als das Factory-Methodenmuster, lässt sich aber leichter erweitern.
Das abstrakte Fabrikmuster gruppiert Produktunterkategorien desselben Typs in einer Kategorie, lässt sie dieselbe abstrakte Unterkategorie erben, behandelt sie dann als Gruppe und gruppiert dann mehrere Gruppen zu einer Familie.
Wenn wir zum Beispiel immer noch die oben genannten Spiele spielen, können wir uns LOL und WOW als Spiele vom Typ PVP vorstellen, oder wir können uns <🎜 vorstellen > DNF und WOW werden als Spiele vom Typ PVE behandelt.

Dann lautet der entsprechende geänderte Code wie folgt:

Codebeispiel:

    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();
    }
    
}

Nach dem Login kopieren

Ausgabeergebnis:

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

Nach dem Login kopieren

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