设计模式之门面模式（外观模式）（十一）

淡淡的烟草味﹌ 2022-05-23 06:08 123阅读 0赞

说到了门面模式，有些地方又叫做外观模式，这个模式在平时做Web项目中应该是经常用到，像我们的Service层与DAO层，就是用到了门面模式，Controller层本来是需要跟一个个DAO打交道，但是有了Service层，它直接与DAO打交道，Controller就可以直接使用Service，我们只需专注在Service上写业务逻辑与操作DAO的各种方法，分离了责任，这个模式我认为最重要的功能就是解耦，降低了系统复杂度。

**定义：外观模式是软件工程中常用的一种软件设计模式。它为子系统中的一组接口提供一个统一的高层接口。这一接口使得子系统更加容易使用。**

![70][]

定义与类图来自百度百科。

我们可以从定义与类图知道，门面模式就是为所有的子系统提供一个统一的高层的接口，负责子系统集合的功能的使用，下面举个例子，更清晰的了解这个模式。这里我举个在京东买键盘鼠标的例子。

首先是各个子系统，也就是各个京东的店家，有卖电脑的实体店，有卖键盘的实体店。

package test;
    
    public class ComputerStore {
    
    	public void getComputer() {
    		System.out.println("从仓库里拿电脑");
    	}
    
    	public void sendComputer() {
    		System.out.println("让快递把电脑寄给买家");
    	}
    
    }

package test;
    
    public class KeyboardStore {
    
    	public void getKeyboard() {
    		System.out.println("从仓库里拿键盘");
    	}
    
    	public void sendShoes() {
    		System.out.println("让快递把键盘寄给买家");
    	}
    
    }

然后就是门面了，也就是某东，客户端这里只需要上某东进行购物就可以了。

package test;
    
    public class Jingdong {
    
    	private ComputerStore computerStore;
    
    	private KeyboardStore keyboardStore;
    
    	public Jingdong() {
    		computerStore = new ComputerStore();
    		keyboardStore = new KeyboardStore();
    	}
    
    	public void buyComputer() {
    
    		computerStore.getComputer();
    		computerStore.sendComputer();
    
    	}
    
    	public void buyKeyboard() {
    
    		keyboardStore.getKeyboard();
    		keyboardStore.sendShoes();
    
    	}
    
    }

下面是客户端实现

package test;
    
    public class Client {
    
    	public static void main(String[] args) {
    
    		Jingdong jingdong = new Jingdong();
    		jingdong.buyComputer();
    		jingdong.buyKeyboard();
    
    	}
    
    }

控制台打印

![70 1][]

客户端是不是很简单，这里客户端只需要跟门面（某东）打交道，不需要本人特地去实体店进行购物，这也体现了网店的便利。如果没有门面（某东），客户端需要自己去new一个电脑店，然后再调用电脑店的两个方法，这样客户端就依赖具体的子系统（电脑店），其实有做过Web项目的应该都很清楚这个模式，正如开头所说它让Controller与DAO解耦，具体的DAO操作SQL查询的业务逻辑放到了Service这个门面上去实现，具体的客户端（Controller）只需要调用Service这个门面实现好了的方法即可。

在实际使用的时候，接口不是必须的，就像我上面举的例子，为了便捷就没写接口了，实际上根据依赖倒置原则，无论高层的外观层，还是底层的子系统，都应该依赖于抽象（接口），这会使得代码规范，便于维护，面向接口编程相信设计模式学到这里都能感受到其强大之处，但缺点是接口会增多，复杂性就增加了，而且我们会经常给Service里添加方法，比如查询XXX，更新XXX，这样需要经常修改接口，这该怎么办呢，一般是等接口的行为稳定的时候，在代码重构的阶段再决定是否添加抽象的接口，应该是一个解决方式。

注：由于我的水平有限，有些地方说的可能有问题?欢迎大家指出，互相讨论互相学习进步！

[70]: /images/20220523/11a3de7620f54ab8bd279d8ccec7d826.png
[70 1]: /images/20220523/129619ca4bf145dfa666b23b9fb5849d.png