Java門面模式舉例分析

本篇內(nèi)容介紹了“Java門面模式舉例分析”的有關知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓小編帶領大家學習一下如何處理這些情況吧！希望大家仔細閱讀，能夠學有所成！

    隨著系統(tǒng)的不斷改進和開發(fā)的深入，它們會變得越來越復雜，系統(tǒng)會生成大量的類，這使得程序更難被理解。門面模式可謂這些類提供一個簡化的接口，從而簡化訪問這些類的復雜性，有時候這種簡化可能降低訪問這些底層累的靈活性，但除了要求特別苛刻的客戶端之外（即調(diào)用方法的類），它通常都可以提供所需的全部功能。當然，那些苛刻的客戶端仍然可以直接訪問底層的類和方法。

    門面（Facade）模式也被稱為正面模式、外觀模式，這種模式用于將一組復雜的類包裝到一個簡單的外部接口中。

    現(xiàn)在考慮這樣的場景：我們有一個顧客需要到飯店用餐，這就需要定義一個Customer類，并為該類定義一個haveDinner方法。假設該飯店有三個部門：收銀部、廚師部和服務生部，用戶就餐需要這三個部門協(xié)調(diào)才能完成。本示例程序先定義一個收銀部，用戶需要調(diào)用該部門的pay方法：

public class PaymentImpl implements Payment {
    public String pay(double price) {
        String food = "快餐"；
        System.out.println("您已付款：" + price + "元，購買的是：" + food);
        return food;
    }
}

    接下來定義廚師部門：

public class CookImpl implements Cook {
    public String cook(String food) {
        System.out.println("廚師正在烹調(diào)：" + food);
    }
}

    服務生部門：

public class WaiterImpl implements Waiter {
    public void serve(String food) {
        System.out.println("服務員正在端菜：" + food);
    }
}

    接下來實現(xiàn)Customer類的haveDinner方法：

public class Customer {
    public void haveDinner() {
        //依次創(chuàng)建三個部門
        Payment payment = new PaymentImpl();
        Cook cook = new CookImpl();
        Waiter waiter = new WaiterImpl();
        //依次調(diào)用三個部門的不同方法
        String food = payment.pay();
        cook.cook(food);
        waiter.serve(food);
        //直接依賴于Facade類來實現(xiàn)用餐方法
        Facade f = new Facade();
        f.serveFood();
    }
}

    正如上面的代碼所示，Customer需要依次調(diào)用三個部門的方法才能完成這個haveDinner方法，實際上，如果這個飯店有更多的部門，那么程序就需要調(diào)用更多部門的方法來實現(xiàn)這個haveDinner方法——這就會增加haveDinner方法的實現(xiàn)難度了。

    為了解決這個問題，我們可以為Payment、Cook、Waiter三個部門提供一個門面（Facade），使用Facade來包裝這些類，對外提供一個簡單的訪問方法：

public class Facade() {
    //定義被封裝的三個部門
    Payment payment;
    Cook cook;
    Waiter waiter;
    //構造函數(shù)
    public Facade(Payment payment, Cook cook, Waiter waiter) {
        this.payment = payment;
        this.cook = cook;
        this.waiter = waiter;
    }
    public void serveFood() {
        String food = payment.pay();
        cook.cook(food);
        waiter.serve(food);
    }
}

    從Facade代碼可以看出，該門面保證了Payment，Cook和Waiter三個部門，程序對外提供了一個簡單的serveFood方法，該方法對外提供了一個用餐的方法，而底層則依賴于三個部門的pay()，cook()，serve()三個方法。一旦程序提供了這個門面類Facade后，Customer類實現(xiàn)haveDinner方法就變得更加簡單了，下面是通過Facade類實現(xiàn)的haveDinner方法：

public void haveDinner() {
    Facade f = new Facade();
    f.serveFood();
}

    從上面的結構可以看出，如果不采用門面模式，客戶端需要自行決定需要調(diào)用哪些類、哪些方法，并需要按合理的順序來調(diào)用它們才能實現(xiàn)所需的功能。不采用門面模式時，程序有如圖所示的結構：

        然而，使用了門面模式之后，客戶端代碼只需要和門面類進行交互即可，于是，程序結構圖變成了如下樣式：

    其實，Spring的HibernateTemplate類就是使用的門面模式：當我們的程序使用Hibernate的find()方法時，程序只要一行代碼即可得到查詢返回的List。但實際上該find()方法后隱藏了如下代碼：

Session session = sf.openSession();
Query query = session.createQuery(hql);
for(int i=0; i<args.length; i++) {
    query.setParameter(i, args[i]);
}
query.list();

    因此我們可以認為HibernateTemplate是SessionFactory，Session、Query等類的門面。當客戶端程序需要進行持久化查詢時，程序無需調(diào)用這些類，而是直接調(diào)用HibernateTemplate門面類中的相應方法即可。

    除此之外，JavaEE應用里使用業(yè)務邏輯組件來封裝DAO組件也是典型的門面模式——每個業(yè)務邏輯組件（一般是Service層）都是眾多DAO組件的門面，系統(tǒng)的控制器類無需直接訪問DAO組件，而是由業(yè)務邏輯方法來組合多個DAO方法以完成所需功能。而Action只需與業(yè)務邏輯組件交互即可。

“Java門面模式舉例分析”的內(nèi)容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業(yè)相關的知識可以關注億速云網(wǎng)站，小編將為大家輸出更多高質量的實用文章！