设计模式八之外观模式
软件系统中,当一个系统的功能越来越强,子系统会越来越多,客户端对系统的访问也会变得越来越复杂。这时如果系统内部发生改变,客户端也要跟着改变,这违背了“开闭原则”,也违背了“迪米特法则”,所以有必要为多个子系统提供一个统一的接口,从而降低系统的耦合度,这就是外观模式的目标。
1. 模式的定义与特点
1.1 模式的定义
外观模式(Facade):为多个复杂的子系统提供一个对外的接口,使这些子系统更加容易的被访问。该模式对外有一个统一的接口,外部应用不用关心子系统内部的细节,大大降低了应用程序的复杂度,提高了可维护性。
1.2 模式的特点
外观模式是“迪米特法则(最少知道原则)“的典型应用,其优点为:
1. 简化了调用过程,应用无需深入了解子系统;
2. 减少系统依赖,松散耦合;
3. 更好的划分访问层次;
4. 符合迪米特法则,即最少知道原则。
外观模式的缺点有:
1. 增加子系统,扩展子系统行为容易引入风险;
2. 不符合开闭原则。
1.3 模式的使用场景
1. 子系统越来越复杂,增加外观模式提供简单调用接口;
2. 构建多层系统结构,利用外观对象作为每层的入口,简化层级调用。
2. 模式的结构与实现
2.1 模式的结构
外观模式的结构比较简单,主要定义了一个高层接口,它包含了对多个子系统的引用,客户端可以通过它来访问各个子系统的功能。外观模式包含以下主要角色:
1. 外观角色(Facade):为多个子系统对外提供一个共同的接口;
2. 子系统角色(Sub System):实现系统的部分功能,客户端可以通过外观角色访问它;
3. 客户端角色(Client):通过外观角色访问各个子系统的功能。
2.2 模式的实现
/**
* 礼品类
*/
public class Gift {
private String name;
public Gift(String name) {
this.name = name;
}
public String getName() {
return name;
}
}
子系统角色
/**
* 积分服务
*/
public class CoinService {
/**
* 检查积分是否足够兑换
* @param gift
* @return
*/
public boolean isCoinEnough(Gift gift) {
System.out.println("兑换" + gift.getName() + ",积分扣减成功");
return true;