[Design Mode Mode Appearance (concept | Applicable scene | pros and cons | sample code)

I. Facade pattern concept

---

1. Appearance mode concept:

① design pattern type: structured;

② standard definition: provides a unified interface for accessing a group of the interface subsystem;

③ hide the complexity of purpose: the definition of a high-level interface that allows the subsystem easier to use, the purpose is to hide the complexity of the system;

④ interaction process: multiple subsystems to complete a joint operation, providing a unified interface for client calls, the client does not perform complex interactions with each subsystem, the client interacts only with the appearance of the class that provides an interface;

2. Aspect Mode related roles:

① Appearance role: the appearance of class has its own method, the user can look like method by calling, calling functional subsystems provided;

② Roles subsystem: may be a plurality of processing modules, one or more of the number;

③ user roles: the user invokes the look class by functional subsystem;

II. Appearance Model application scenarios

---

Aspect Mode application scenarios:

① subsystem Complex: subsystems complex, can be simplified by using a look mode call interface;

Complex ② level: the system structure complex hierarchy, each level have a look object is used as the inlet layer, can simplify the interface between the calling hierarchy;

III. Disadvantages Appearance Model

---

1. Appearance Model advantages:

① simplify call: to simplify the calling process is a complex system, without the need for an in-depth understanding of the subsystem to complete the call;

② lower coupling: using appearance model only interacts with the appearance of the object, without direct interaction with complex subsystems, reducing the dependence between systems, so that lower coupling relationship; the internal subsystems and modules easier to maintain expansion;

③ Control level: complex hierarchy system, some methods require an external call to the system, some methods require the use internally, the functions provided to the external appearance of the class definition, so convenient to call, internal systems can also details hidden;

④ meet Demeter: Minimum know principle, the user does not need to know the internal subsystem, the subsystem does not need to interact with, interacts only with the appearance of the class; reducing the coupling between the subsystem and the application layer;

2. Appearance Model disadvantages:

① expansion subsystem risk: internal system expansion subsystem, prone to risk;

② does not comply with the principle of opening and closing: the appearance mode, when the expansion subsystem does not comply with the principle of opening and closing;

IV. Appearance model and other design patterns and Differences

---

1. Appearance mode and intermediary model:

① Aspect Mode: Facade pattern concerns the interaction between external users and subsystems;

② intermediary model: intermediary model concerns the interaction between the internal subsystems;

2. Appearance Model with singleton: appearance class is typically defined as a singleton;

3. Appearance mode and the abstract factory pattern: appearance class abstract factory, acquiring the object instance of the subsystem, the subsystem can shield the inner skin class;

V. Appearance mode code sample

---

1. Description of Requirement: realize the function of a commodity purchase, the user offered to buy an item, you must first see the stock, then payment, and finally logistics delivery;

① direct user interaction with subsystems: the first storage subsystem and whether there is interaction check stock, and then pay the purchase price paid subsystems interact with, and finally get into the logistics subsystems logistics numbers; use this interactive mode, causing the user subsystem coupled with too high;

② the introduction of skin class: the storage subsystem and pay subsystems, interactions between subsystems unified logistics to deal with the appearance of classes, the user only needs to interact with the appearance of the class object, thereby greatly reducing the user with multiple subsystems coupling between;

2. Code Example plurality of subsystems: three respective processing subsystems of business;

① storage subsystem codes:

package kim.hsl.design.facade;

/**
 * 仓库子系统
 * 查询是否有库存
 */
public class StoreService {
    public boolean isStokeAvailable(Goods goods){
        System.out.println("校验是否有库存 : " + goods.toString() + " 有库存");
        return true;
    }
}

② payment subsystem codes:

package kim.hsl.design.facade;

/**
 * 支付子系统
 * 支付成功返回 true
 */
public class PaymentService {
    public boolean pay(Goods goods){
        System.out.println("使用银联支付");
        return true;
    }
}

③ logistics subsystem codes:

package kim.hsl.design.facade;

/**
 * 物流子系统
 * 进入发货流程 , 返回物流编号
 */
public class LogisticsService {
    public String logistics(Goods goods){
        String logisticsNo = "31415926";
        System.out.println(goods + " 进入物流系统 , 运单号为 " + logisticsNo);
        return logisticsNo;
    }
}

3. Appearance class code: Appearance class maintains three sub-modules, user buyGoods method, as with the three interfaces between the different subsystems;

package kim.hsl.design.facade;

/**
 * 用户购买的统一接口
 * 用户只需要与该类进行交互
 * 该类统一处理 仓储 支付 物流 等购买流程
 */
public class BuyFacade {
    private LogisticsService logisticsService;
    private PaymentService paymentService;
    private StoreService storeService;

    public BuyFacade() {
        storeService = new StoreService();
        paymentService = new PaymentService();
        logisticsService = new LogisticsService();
    }

    /**
     * 外观类提供的访问内部三个子系统的接口
     * 客户端只需要调用该方法 , 即可完整商品购买流程
     * @param goods
     */
    public void buyGoods(Goods goods){
        if(storeService.isStokeAvailable(goods)){
            if(paymentService.pay(goods)){
                logisticsService.logistics(goods);
            }
        }
    }
}

4 commodity codes:

package kim.hsl.design.facade;

/**
 * 商品
 */
public class Goods {
    private String name;
    public Goods(String name) {
        this.name = name;
    }
    @Override
    public String toString() {
        return "Goods{" +
                "name='" + name + '\'' +
                '}';
    }
}

5. Test function entry code:

package kim.hsl.design.facade;

public class Main {
    public static void main(String[] args) {
        Goods goods = new Goods("肥皂");
        BuyFacade buyFacade = new BuyFacade();
        buyFacade.buyGoods(goods);
    }
}

6. The final results of the implementation:

校验是否有库存 : Goods{name='肥皂'} 有库存
使用银联支付
Goods{name='肥皂'} 进入物流系统 , 运单号为 31415926