33.3 包装模式群PK

发表于 2021-09-27 更新于 2021-09-30 分类于 8 设计模式之禅(第2版) ， 3 第三部分谁的地盘谁做主 ——设计模式PK ，第33章跨战区PK Waline：本文字数： 7.7k 阅读时长 ≈ 7 分钟

33.3 包装模式群PK

我们讲了这么多的设计模式，大家有没有发觉在很多的模式中有些角色是不干活的？它们只是充当黔首作用，你有问题，找我，但我不处理，我让其他人处理。最典型的就是代理模式了，代理角色接收请求然后传递到被代理角色处理。门面模式也是一样，门面角色的任务就是把请求转发到子系统。类似这种结构的模式还有很多，我们先给这种类型的模式定义一个名字，叫做包装模式（wrapping pattern）。注意，包装模式是一组模式而不是一个。包装模式包括哪些设计模式呢？包装模式包括：装饰模式、适配器模式、门面模式、代理模式、桥梁模式。下面我们通过一组例子来说明这五个包装模式的区别。

33.3.1 代理模式

现在很多明星都有经纪人，一般有什么事他们都会说：“你找我的经纪人谈好了”，下面我们就看看这一过程怎么模拟。假设有一个追星族想找明星签字，我们看看采用代理模式怎么实现。代理模式是包装模式中的最一般的实现，类图如图33-6所示。

图33-6 追星族找明星签字类图很简单，就是一个简单的代理模式，我们来看明星的定义，明星接口如代码清单33-29所示。

代码清单33-29 明星接口

public interface IStar {
    //明星都会签名
    public void sign();
}

明星只有一个行为：签字。我们来看明星的实现，如代码清单33-30所示。

代码清单33-30 明星

public class Singer implements IStar {
    public void sign() {
        System.out.println("明星签字：我是XXX大明星");
    }
}

经纪人与明星应该有相同的行为，比如说签名，虽然经纪人不签名，但是他把你要签名的笔记本、衣服、CD等传递过去让真正的明星签字，经纪人如代码清单33-31所示。

代码清单33-31 经纪人

public class Agent implements IStar {
    //定义是谁的经纪人
    private IStar star;
    //构造函数传递明星
    public Agent(IStar _star){
        this.star = _star;
    }
    //经纪人是不会签字的，签字了歌迷也不认
    public void sign() {
        star.sign();
    }
}

应该非常明确地指出一个经纪人是谁的代理，因此要在构造函数中接收一个明星对象，确定是要做这个明星的代理。我们再来看看追星族是怎么找明星签字的，如代码清单33-32所示。

代码清单33-32 追星族

public class Idolater {
    public static void main(String[] args) {
        //崇拜的明星是谁
        IStar star = new Singer();
        //找到明星的经纪人
        IStar agent = new Agent(star);
        System.out.println("追星族：我是你的崇拜者，请签名！");
        //签字
        agent.sign();
    }
}

很简单，找到明星的代理，然后明星就签字了。运行结果如下所示：

1 2	追星族：我是你的崇拜者，请签名！明星签字：我是XXX大明星

看看我们的程序逻辑，我们是找明星的经纪人签字，真实签字的是明星，经纪人只是把这个请求传递给明星处理而已，这是普通的代理模式的典型应用。

33.3.2 装饰模式

明星也都是一步一步地奋斗出来的，谁都不是一步就成为大明星的。甚至一些演员通过粉饰自己给观众一个好的印象，现在我们就来看怎么粉饰一个演员，如图33-7所示。

图33-7 演技修饰

下面我们就来看看这些过程如何实现，先看明星接口，如代码清单33-33所示。

代码清单33-33 明星接口

public interface IStar {
    //演戏
    public void act();
}

我们来看看我们的主角，如代码清单33-34所示。

代码清单33-34 假明星

public class FreakStar implements IStar {
    public void act() {
        System.out.println("演中：演技很拙劣");
    }
}

我们看看这个明星是怎么粉饰的，先定义一个抽象装饰类，如代码清单33-35所示。

代码清单33-35 抽象装饰类

public abstract class Decorator implements IStar {
    //粉饰的是谁
    private IStar star;
    public Decorator(IStar _star){
        this.star = _star;
    }
    public void act() {
        this.star.act();
    }
}

前后两次修饰，开演前毫无忌惮地吹嘘，如代码清单33-36所示。

代码清单33-36 吹大话

public class HotAir extends Decorator {
    public HotAir(IStar _star){
        super(_star);
    }
    public void act(){
        System.out.println("演前：夸夸其谈，没有自己不能演的角色");
        super.act();
    }
}

大家发现这个明星演技不好的时候，他拼命找借口，说是那天天气不好、心情不好等，如代码清单33-37所示。

代码清单33-37 抵赖

public class Deny extends Decorator {
    public Deny(IStar _star){
        super(_star);
    }
    public void act(){
        super.act();
        System.out.println("演后：百般抵赖，死不承认");
    }
}

我们建立一个场景把这种情况展示一下，如代码清单33-38所示。

代码清单33-38 场景类

public class Client {
    public static void main(String[] args) {
        //定义出所谓的明星
        IStar freakStar = new FreakStar();
        //看看他是怎么粉饰自己的
        //演前吹嘘自己无所不能
        freakStar = new HotAir(freakStar);
        //演完后，死不承认自己演的不好
        freakStar = new Deny(freakStar);
        System.out.println("====看看一些虚假明星的形象====");
        freakStar.act();
    }
}

运行结果如下所示：

====看看一些虚假明星的形象==== 
演前：夸夸其谈，没有自己不能演的角色 
演中：演技很拙劣 
演后：百般抵赖，死不承认

33.3.3 适配器模式

我们知道在演艺圈中还存在一种情况：替身，替身也是演员，只是普通的演员而已，在一段戏中，前十五分钟是明星本人，后十五分钟也是明星本人，就中间的五分钟是替身，那这个场景该怎么描述呢？注意中间那五分钟，这个时候一个普通演员被导演认为是明星演员，我们来看类图，如图33-8所示。

图33-8 替身演员类图

导演找了一个普通演员作为明星的替身，不过观众看到的还是明星的身份。我们来看代码，首先看明星接口，如代码清单33-39所示。

代码清单33-39 明星接口

public interface IStar {
    //明星都要演戏
    public void act(String context);
}

再来看一个具体的电影明星，他的主要职责就是演戏，如代码清单33-40所示。

代码清单33-40 电影明星

public class FilmStar implements IStar {
    public void act(String context) {
        System.out.println("明星演戏：" + context);
    }
}

我们再来看普通演员，明星就那么多，但是普通演员非常多，我们看其接口，如代码清单33-41所示。

代码清单33-41 普通演员接口

public interface IActor {
    //普通演员演戏
    public void playact(String contet);
}

普通演员也是演员，是要演戏的，我们来看一个普通演员的实现，如代码清单33-42所示。

代码清单33-42 普通演员

public class UnknownActor implements IActor {
    //普通演员演戏
    public void playact(String context) {
        System.out.println("普通演员："+context);
    }
}

我们来看替身该怎么编写，如代码清单33-43所示。

代码清单33-43 替身演员

public class Standin implements IStar {
    private IActor actor;
    //替身是谁
    public Standin(IActor _actor){
        this.actor = _actor;
    }
    public void act(String context) {
        actor.playact(context);
    }
}

这是一个通用的替身，哪个普通演员能担任哪个明星的替身是由导演决定的，导演想让谁当就让谁当，我们来看导演，如代码清单33-44所示。

代码清单33-44 导演类

public class direcotr {
    public static void main(String[] args) {
        System.out.println("=======演戏过程模拟==========");
        //定义一个大明星
        IStar star = new FilmStar();
        star.act("前十五分钟，明星本人演戏");
        //导演把一个普通演员当做明星演员来用
        IActor actor = new UnknownActor();
        IStar standin= new Standin(actor);
        standin.act("中间五分钟，替身在演戏");
        star.act("后十五分钟，明星本人演戏");
    }
}

运行结果如下所示：

=======演戏过程模拟========== 
明星演戏：前十五分钟，明星本人演戏 
普通演员：中间五分钟，替身在演戏 
明星演戏：后十五分钟，明星本人演戏

33.3.4 桥梁模式

我们继续说明星圈的事情，现在明星类型太多了，比如电影明星、电视明星、歌星、体育明星、网络明星等，每个类型的明星都有明确的职责，电影明星的主要工作就是演电影，电视明星的主要工作就是演电视剧或者主持电视节目。再看看现在的明星，单一发展的基本没有，主持人出专辑、体育明星演电影、歌星拍戏等太平常了，我们就用程序来表现一下多元化情形，如图33-9所示。

图33-9 各类明星描述

图33-9中定义了一个抽象明星AbsStar，然后产生出各个具体类型的明星，比如电影明星FilmStar、歌星Singer，当然还可以继续扩展下去。这里还定义了一个抽象的行为AbsAction，描述明星所具有的活动，比如演电影、唱歌等，在这种设计下，明星可以扩展，明星的活动也可以扩展，非常灵活。我们先来看明星的活动，抽象活动如代码清单33- 45所示。

代码清单33-45 抽象活动

public abstract class AbsAction {
    //每个活动都有描述
    public abstract void desc();
}

很简单，只有一个活动的描述，由子类来实现。我们来看演电影和唱歌两个活动，分别如代码清单33-46、33-47所示。

代码清单33-46 演电影

public class ActFilm extends AbsAction {
    public void desc() {
        System.out.println("演出精彩绝伦的电影");
    }
}

代码清单33-47 唱歌

public class Sing extends AbsAction {
    public void desc() {
        System.out.println("唱出优美的歌曲");
    }
}

各种精彩的活动都有了，我们再来看抽象明星，它是所有明星的代表，如代码清单33- 48所示。

代码清单33-48 抽象明星

public abstract class AbsStar {
    //一个明星参加哪些活动
    protected final AbsAction action;
    //通过构造函数传递具体活动
    public AbsStar(AbstAction _action){
        this.action = _action;
    }
    //每个明星都有自己的主要工作
    public void doJob(){
        action.desc();
    }
}

明星都有自己的主要活动（或者是主要工作），我们在抽象明星中只是定义明星有活动，具体有什么活动由各个子类实现。我们再来看电影明星，如代码清单33-49所示。

代码清单33-49 电影明星

public class FilmStar extends AbsStar {
    //默认的电影明星的主要工作是拍电影
    public FilmStar(){
        super(new ActFilm());
    }
    //也可以重新设置一个新职业
    public FilmStar(AbsAction _action){
        super(_action);
    }
    //细化电影明星的职责
    public void doJob(){
        System.out.println("\n======影星的工作=====");
        super.doJob();
    }
}

电影明星的本职工作就应该是演电影，因此就有了一个无参构造函数来定义电影明星的默认工作，如果明星要客串一下去唱歌也可以，有参构造解决了该问题。歌星的实现与此相同，如代码清单33-50所示。

代码清单33-50 歌星

public class Singer extends AbsStar {
    //歌星的默认活动是唱歌
    public Singer(){
        super(new Sing());
    }
    //也可以重新设置一个新职业
    public Singer(AbsAction _action){
        super(_action);
    }
    //细化歌星的职责
    public void doJob(){
        System.out.println("\n======歌星的工作=====");
        super.doJob();
    }
}

我们使用电影明星和歌星来作为代表，这两类明星也是我们经常听到或看到的，下面建立一个场景类来模拟一下明星的事迹，如代码清单33-51所示。

代码清单33-51 场景类

public class Client {
    public static void main(String[] args) {
        //声明一个电影明星
        AbsStar zhangSan = new FilmStar();
        //声明一个歌星
        AbsStar liSi = new Singer();
        //展示一下各个明星的主要工作
        zhangSan.doJob();
        liSi.doJob();
        //当然，也有部分明星不务正业，比如歌星演戏
        liSi = new Singer(new ActFilm());
        liSi.doJob();
    }
}

运行结果如下所示：

======影星的工作===== 
演出精彩绝伦的电影 
======歌星的工作===== 
唱出优美的歌曲 
======歌星的工作===== 
演出精彩绝伦的电影

好了，各类明星都有自己的本职工作，但是偶尔客串一个其他类型的活动也是允许的，如此设计后，明星就可以不用固定在自己的本职工作上，而是向其他方向发展，比如影视歌三栖明星。

门面模式我们在其他章节已经讲解得比较多了，本小节就不再赘述。

33.3.5 最佳实践

5个包装模式是大家在系统设计中经常会用到的模式，它们具有相似的特征：都是通过委托的方式对一个对象或一系列对象（例如门面模式）施行包装，有了包装，设计的系统才更加灵活、稳定，并且极具扩展性。从实现的角度来看，它们都是代理的一种具体表现形式，我们来看看它们在使用场景上有什么区别。

代理模式主要用在不希望展示一个对象内部细节的场景中，比如一个远程服务不需要把远程连接的所有细节都暴露给外部模块，通过增加一个代理类，可以很轻松地实现被代理类的功能封装。此外，代理模式还可以用在一个对象的访问需要限制的场景中，比如AOP。

装饰模式是一种特殊的代理模式，它倡导的是在不改变接口的前提下为对象增强功能，或者动态添加额外职责。就扩展性而言，它比子类更加灵活，例如在一个已经运行的项目中，可以很轻松地通过增加装饰类来扩展系统的功能。

适配器模式的主要意图是接口转换，把一个对象的接口转换成系统希望的另外一个接口，这里的系统指的不仅仅是一个应用，也可能是某个环境，比如通过接口转换可以屏蔽外界接口，以免外界接口深入系统内部，从而提高系统的稳定性和可靠性。

桥梁模式是在抽象层产生耦合，解决的是自行扩展的问题，它可以使两个有耦合关系的对象互不影响地扩展，比如对于使用笔画图这样的需求，可以采用桥梁模式设计成用什么笔（铅笔、毛笔）画什么图（圆形、方形）的方案，至于以后需求的变更，如增加笔的类型，增加图形等，对该设计来说是小菜一碟。

门面模式是一个粗粒度的封装，它提供一个方便访问子系统的接口，不具有任何的业务逻辑，仅仅是一个访问复杂系统的快速通道，没有它，子系统照样运行，有了它，只是更方便访问而已。