Modèles de conception Java - Modèle d'apparence

Aperçu

Le modèle d'apparence dont je vais parler aujourd'hui est un modèle de conception relativement simple, et dans le développement quotidien, vous pouvez également l'utiliser de temps en temps, mais vous n'avez peut-être pas pensé que c'est un modèle de conception. Cet article commencera par quelques exemples pour expliquer le mode d'apparence qui sera expliqué dans cet article de manière aussi complète que possible. J'espère que cela vous sera bénéfique.

Introduction

Le but d'insérer une citation ici est de vous permettre de vous rappeler quand vous utilisez le modèle d'apparence dans votre développement quotidien.

Peut-être que votre patron vous organisera une tâche comme celle-ci. Il peut s'agir d'un module de base, et le module aura une de ses fonctions, mais votre patron voudra peut-être uniquement que vous lui fournissiez une interface à appeler. Il vous dira ceci : Bonjour, Xiao Ming, notre système actuel a besoin d'une fonction principale P0, laissez-vous l'implémenter. Il vous suffit de me donner une interface que je peux appeler. Je n'ai pas besoin de connaître la logique interne de votre code. Fais-le c'est tout.

Si de telles tâches vous sont souvent confiées, je pense que vous auriez dû maîtriser le mode apparence.

Définition

Le modèle d'apparence fournit une interface unifiée pour accéder à un groupe d'interfaces dans un sous-système. Le modèle de façade définit une interface de haut niveau qui facilite l'utilisation des sous-systèmes.

Mode de non-apparence

Ici, je vais utiliser l'exemple du livre "Dahua Design Patterns". Je pense que cet exemple est assez vivant. Imaginez maintenant que vous êtes un investisseur en actions (c'est juste que le blogueur ne négocie pas d'actions, et je ne sais pas s'il y a quelque chose qui ne va pas ici. Si c'est le cas, faites comme si vous ne l'aviez pas vu. ^_^) , et vous souhaitez effectuer certaines activités de gestion financière. Vous êtes intéressé par deux actions, un bon du Trésor et un immobilier.

Si vous deviez écrire ce code maintenant, votre cadre de code pourrait ressembler au diagramme de classes suivant :

Seules les actions sont répertoriées ici, car la logique des autres activités de gestion financière est conforme à la logique des stocks. Le code redondant n’a pas plus d’avantages que de prendre de la place.

StockA.java

public class StockA {
    private int stockCount = 0;
    public void sell(int count){
        stockCount -= count;
        System.out.println("卖了" + count + "支 A 股票");
    }

    public void buy(int count){
        stockCount += count;
        System.out.println("买了" + count + "支 A 股票");
    }
    public int getStockCount() {
        return stockCount;
    }
}

Le code suivant est destiné aux directeurs financiers. Pour une logique d'achat et de vente simple, les directeurs financiers doivent consacrer autant de temps au traitement du code.

Investors.java

public class Investors {

    public static void main(String[] args) {
        StockA stockA = new StockA();
        StockB stockB = new StockB();
        NationalDebt debt = new NationalDebt();
        RealEstate estate = new RealEstate();

        stockA.buy(100);
        stockB.buy(200);
        debt.buy(150);
        estate.buy(120);

        stockA.sell(100);
        stockB.sell(200);
        debt.sell(150);
        estate.sell(120);
    }
}

Le code mentionné ci-dessus est écrit sans utiliser le mode apparence. En d’autres termes, le mode d’apparence mentionné ci-dessous peut rendre le code plus simple et plus clair.

Mode d'apparence

Dans le mode de non-apparence ci-dessus, nous voyons une logique de code qui n'est pas très conviviale. Le mode d'apparition peut être basé sur un niveau d'encapsulation plus élevé pour être plus transparent pour l'appelant. Voici le diagramme de classes du mode d'apparence modifié :

FundFacade.java

public class FundFacade {

    private StockA stockA = null;
    private StockB stockB = null;
    private NationalDebt debt = null;
    private RealEstate estate = null;

    public FundFacade() {
        stockA = new StockA();
        stockB = new StockB();
        debt = new NationalDebt();
        estate = new RealEstate();
    }

    public void buyAll(int count) {
        stockA.buy(count);
        stockB.buy(count);
        debt.buy(count);
        estate.buy(count);
    }

    public void sellAll(int count) {
        stockA.sell(count);
        stockB.sell(count);
        debt.sell(count);
        estate.sell(count);
    }

    public void buyStockA(int count) {
        stockA.buy(count);
    }

    public void sellNationalDebt(int count) {
        debt.sell(count);
    }
}

Le code ci-dessus est la classe d'apparence principale : FundFacade. Toutes les opérations du système de gestion financière peuvent être mises en œuvre via cette classe. Grâce à ce cours, vous pouvez facilement gérer des projets de gestion financière tels que des actions, des bons du Trésor et de l'immobilier sans vous soucier de la façon dont ils sont traités. C'est une bonne chose pour les utilisateurs, n'est-ce pas ?

Jetons un coup d'œil au fonctionnement de l'utilisateur (bien sûr, le diagramme ci-dessus a reflété la plupart des effets), voici la logique du code de l'utilisateur :

Investors.java

public class Investors {

    public static void main(String[] args) {
        FundFacade facade = new FundFacade();
        facade.buyAll(120);
        facade.buyStockA(50);
        facade.sellAll(80);
    }
}

Écoutez, l'utilisateur n'a qu'à dire à la classe FundFacade quoi acheter, quoi vendre, combien acheter, combien vendre, et l'objectif peut être atteint. C'est tellement pratique.

Regardez le code du stock A. En fait, il n'a pas de changements substantiels. C'est aussi le charme du mode apparence. Il ne nécessite pas de modifier le code du sous-système d'origine. Il vous suffit de faire une chose et de construire une encapsulation de niveau supérieur. Bien sûr, j'ai apporté ici quelques modifications simples pour accéder au StockA. Puisqu'il doit être transparent pour les utilisateurs, mon sous-système n'a plus besoin d'être ouvert aux utilisateurs, n'est-ce pas ? Parce que nous avons déjà des diplomates professionnels - FundFacade.

StockA.java

class StockA {
    private int stockCount = 0;
    void sell(int count){
        stockCount -= count;
        System.out.println("卖了" + count + "支 A 股票");
    }

    void buy(int count){
        stockCount += count;
        System.out.println("买了" + count + "支 A 股票");
    }
    int getStockCount() {
        return stockCount;
    }
}

Le modèle d'apparence est un modèle de conception relativement simple que vous pouvez facilement maîtriser et utiliser. Je veux juste dire que le mode apparence a également certaines limites. Je crois que vous l'avez découvert.

Puisque nous confions toutes les opérations sur le sous-système à la classe FundFacade, nous sommes contraints par la classe FundFacade. Par exemple, la classe FundFacade ci-dessus n'implémente pas d'opérations distinctes sur StockB, nous ne pouvons donc pas opérer sur StockB uniquement à moins que vous n'encapsuliez une interface pour faire fonctionner StockB dans la classe FundFacade.

Application du mode Apparence

Dans la description ci-dessus, nous savons non seulement comment utiliser le mode Apparence, mais comprenons également les limites du mode Apparence, nous devons donc adopter une position objective et être sélectif Utilisez-le. Voici un exemple de la façon dont j'utilise le mode apparence dans mon travail.

Le patron du projet actuel m'a demandé d'implémenter un certain module dans un système. Je pense que cela devrait être un module de base. La fonction de ce module est de vérifier si tous les fichiers d'un dossier contiennent des informations sensibles. Il y aura beaucoup de petits sous-modules dans ce module (bien sûr le patron ne se souciera pas de ce que font ces sous-modules), comme la correspondance de modèles d'automates AC, la décompression entièrement automatique des fichiers compressés, les fichiers de formats variés (doc/xls / ppt/zip/eml/rtf/pdf, etc., la plupart des formats de fichiers sont essentiellement là), système de journalisation, etc.

Je ne peux pas dire au patron que la fonction que vous souhaitez remplir est ce que vous devez faire en premier, que devez-vous faire ensuite, que devez-vous faire ensuite, que devez-vous faire à nouveau...

Oh, oh mon dieu. C'est tellement ennuyeux, peux-tu l'encapsuler ? (Bien sûr, ce ne sont que mes activités mentales. En fait, je n'ai pas demandé au patron d'expliquer mon processus de conception)

Après l'encapsulation, il me suffit de dire au patron d'appeler cette méthode de cette classe et ça ira. De cette façon, le patron n'a pas à se soucier de la logique interne. Même si quelque chose ne va pas, cela devrait être votre responsabilité. Ha ha. . .

Bon, c'est fini pour les conneries. Qu'il s'agisse de l'explication détaillée du modèle sérieux ci-dessus ou des absurdités ci-dessous, j'espère que cela vous permettra de bien comprendre le modèle de conception dans cet article, de l'apprendre et de l'utiliser de manière rationnelle.

Ce qui précède est le contenu du modèle de conception Java - modèle d'apparence. Pour plus de contenu connexe, veuillez faire attention au site Web PHP chinois (m.sbmmt.com) !