蓝蓝站点

Java读书笔记

发表于 更新于 分类于 ， ， Waline： 本文字数： 3.5k 阅读时长 ≈ 3 分钟

12.1 我是游戏至尊

2007年，感觉很无聊，于是就玩了一段时间的网络游戏，游戏名就不说了，反正就是打怪、升级、砍人、被人砍，然后继续打怪、升级、打怪、升级……我花了两个月的时间升到80级，已经很有成就感了，但是还会被人杀死，高手到处都是，GM（Game Master，游戏管理员）也不管，对于咱这种非RMB玩家基本上都是懒得搭理。在这段时间我是体会到网络游戏的乐与苦，参与家族（工会）攻城，胜利后那叫一个乐呀，感觉自己真是一个“狂暴战士”，无往不胜！那苦是什么呢？就是升级，为了升一级，就要到处杀怪，做任务，那个游戏还很变态，外挂管得很严，基本上出个外挂，没两天就开始封账号，不敢用，升级基本上都要靠自己手打，累呀！我曾经的记录是连着打了23个小时，睡觉在梦中还和大BOSS在PK。有这样一段经历还是很有意思的，作为架构师是不是可以把这段经历通过架构的方式记录下来呢？当然可以了，我们把这段打游戏的过程系统化，非常简单的一个过程，如图12-1所示。

image-20210928170514558

图12-1 游戏过程
太简单了，定义一个接口IGamePlayer，是所有喜爱网络游戏的玩家，然后定义一个具体的实现类GamePlayer，实现每个游戏爱好者为了玩游戏要执行的功能。代码也非常简单，我们先来看IGamePlayer，如代码清单12-1所示。

代码清单12-1 游戏者接口

1
2
3
4
5
6
7
8
public interface IGamePlayer {
    //登录游戏
    public void login(String user,String password);
    //杀怪，网络游戏的主要特色
    public void killBoss();
    //升级
    public void upgrade();
}

非常简单，定义了三个方法，分别是我们在网络游戏中最常用的功能：登录游戏、杀怪和升级，其实现类如代码清单12-2所示。

代码清单12-2 游戏者

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
public class GamePlayer implements IGamePlayer {
    private String name = "";
    //通过构造函数传递名称
    public GamePlayer(String _name){
        this.name = _name;
    }
    //打怪，最期望的就是杀老怪
    public void killBoss() {
        System.out.println(this.name + "在打怪！");
    }
    //进游戏之前你肯定要登录吧，这是一个必要条件
    public void login(String user, String password) {
        System.out.println("登录名为"+user+"的用户"+this.name+"登录成功！");
    }
    //升级，升级有很多方法，花钱买是一种，做任务也是一种
    public void upgrade() {
        System.out.println(this.name + " 又升了一级！");
    }
}

在实现类中通过构造函数传递进来玩家姓名，方便进行后期的调试工作。我们通过一个场景类来模拟这样的游戏过程，如代码清单12-3所示。

代码清单12-3 场景类

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
public class Client {
    public static void main(String[] args) {
        //定义一个痴迷的玩家
        IGamePlayer player = new GamePlayer("张三");
        
        //开始打游戏，记下时间戳
        System.out.println("开始时间是：2009-8-25 10:45");
        player.login("zhangSan", "password");
        //开始杀怪
        player.killBoss();
        //升级
        player.upgrade();
        //记录结束游戏时间
        System.out.println("结束时间是：2009-8-26 03:40");
    }
}

程序记录了游戏的开始时间和结束时间，同时也记录了在游戏过程中都需要做什么事情，运行结果如下：

1
2
3
4
5
开始时间是：2009-8-25 10:45 
登录名为zhangSan 的用户 张三登录成功！ 
张三在打怪！ 
张三 又升了一级！ 
结束时间是：2009-8-26 03:40

运行结果也是我们想要的，记录我这段时间的网游生涯。心理学家告诉我们，人类对于苦难的记忆比对喜悦的记忆要深刻，但是人类对于喜悦是“趋利”性的，每个人都想Happy， 都不想让苦难靠近，要想获得幸福，苦难也是在所难免的，我们的网游生涯也是如此。游戏打时间长了，腰酸背痛、眼睛干涩、手臂酸麻，等等，也就是网络成瘾综合症都出来了。其结果就类似吃了那个“一日丧命散”，“筋脉逆流，胡思乱想，而致走火入魔”。那怎么办呢？ 我们想玩游戏，但又不想碰触到游戏中的烦恼，如何解决呢？有办法，现在游戏代练的公司非常多，我把自己的账号交给代练人员，由他们去帮我升级，去打怪，非常好的想法，我们来修改一下类图，如图12-2所示。

image-20210928170815982

图12-2 游戏代练帮忙打怪

在类图中增加了一个GamePlayerProxy类来代表游戏代练者，它也不能有作弊的方法呀， 游戏代练者也是手动打怪呀，因此同样继承IGamePlayer接口，其实现如代码清单12-4所示。

代码清单12-4 代练者

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
public class GamePlayerProxy implements IGamePlayer {
    private IGamePlayer gamePlayer = null;
    //通过构造函数传递要对谁进行代练
    public GamePlayerProxy(IGamePlayer _gamePlayer){
        this.gamePlayer = _gamePlayer;
    }
    //代练杀怪
    public void killBoss() {
        this.gamePlayer.killBoss();
    }
    //代练登录
    public void login(String user, String password) {
        this.gamePlayer.login(user, password);
    }
    //代练升级
    public void upgrade() {
        this.gamePlayer.upgrade();
    }
}

很简单，首先通过构造函数说明要代谁打怪升级，然后通过手动开始代用户打怪、升级。场景类Client代码也稍作改动，如代码清单12-5所示。

代码清单12-5 改进后的场景类

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
public class Client {
    public static void main(String[] args) {
        //定义一个痴迷的玩家
        IGamePlayer player = new GamePlayer("张三");
        //然后再定义一个代练者
        IGamePlayer proxy = new GamePlayerProxy(player);
        //开始打游戏，记下时间戳
        System.out.println("开始时间是：2009-8-25 10:45");
        proxy.login("zhangSan", "password");
        //开始杀怪
        proxy.killBoss();
        //升级
        proxy.upgrade();
        //记录结束游戏时间
        System.out.println("结束时间是：2009-8-26 03:40");
    }
}

运行结果也完全相同，还是张三这个用户在打怪，运行结果如下：

1
2
3
4
5
开始时间是：2009-8-25 10:45 
登录名为zhangSan 的用户 张三登录成功！ 
张三在打怪！ 
张三 又升了一级！ 
结束时间是：2009-8-26 03:40

是的，没有任何改变，但是你有没有发觉，你的游戏已经在升级，有人在帮你干活了！ 终于升级到120级，基本上在本服务区，除了GM外，这个你可惹不起！这就是代理模式。

发表于 更新于 分类于 ， ， Waline： 本文字数： 1.7k 阅读时长 ≈ 2 分钟

12.2 代理模式的定义

代理模式（Proxy Pattern）是一个使用率非常高的模式，其定义如下：

Provide a surrogate or placeholder for another object to control access to it.（为其他对象提供一种代理以控制对这个对象的访问。）

代理模式的通用类图如图12-3所示。

image-20210928171355793

图12-3 代理模式的通用类图

代理模式也叫做委托模式，它是一项基本设计技巧。许多其他的模式，如状态模式、策略模式、访问者模式本质上是在更特殊的场合采用了委托模式，而且在日常的应用中，代理模式可以提供非常好的访问控制。在一些著名开源软件中也经常见到它的身影，如Struts2的Form元素映射就采用了代理模式（准确地说是动态代理模式）。我们先看一下类图中的三个角色的定义：

  • Subject抽象主题角色

抽象主题类可以是抽象类也可以是接口，是一个最普通的业务类型定义，无特殊要求。

  • RealSubject具体主题角色

也叫做被委托角色、被代理角色。它才是冤大头，是业务逻辑的具体执行者。

  • Proxy代理主题角色

也叫做委托类、代理类。它负责对真实角色的应用，把所有抽象主题类定义的方法限制委托给真实主题角色实现，并且在真实主题角色处理完毕前后做预处理和善后处理工作。

我们首先来看Subject抽象主题类的通用源码，如代码清单12-6所示。

代码清单12-6 抽象主题类

1
2
3
4
public interface Subject {
    //定义一个方法
    public void request();
}

在接口中我们定义了一个方法request来作为方法的代表，RealSubject对它进行实现，如代码清单12-7所示。

代码清单12-7 真实主题类

1
2
3
4
5
6
public class RealSubject implements Subject {
    //实现方法
    public void request() {
        //业务逻辑处理
    }
}

RealSubject是一个正常的业务实现类，代理模式的核心就在代理类上，如代码清单12-8 所示。

代码清单12-8 代理类

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
public class Proxy implements Subject {
    //要代理哪个实现类
    private Subject subject = null;
    //默认被代理者
    public Proxy(){
        this.subject = new Proxy();
    }
    //通过构造函数传递代理者
    public Proxy(Object...objects ){
        
    }
    //实现接口中定义的方法
    public void request() {
        this.before();
        this.subject.request();
        this.after();
    }
    //预处理
    private void before(){
        //do
    something }
    //善后处理
    private void after(){
        //do
    something }
}

看到这里，大家别惊讶，为什么会出现before和after方法，继续看下去，这是一个“引子”，能够引出一个崭新的编程模式。

一个代理类可以代理多个被委托者或被代理者，因此一个代理类具体代理哪个真实主题角色，是由场景类决定的。当然，最简单的情况就是一个主题类和一个代理类，这是最简洁的代理模式。在通常情况下，一个接口只需要一个代理类就可以了，具体代理哪个实现类由高层模块来决定，也就是在代理类的构造函数中传递被代理者，例如我们可以在代理类Proxy中增加如代码清单12-9所示的构造函数。

代码清单12-9 代理的构造函数

1
2
3
public Proxy(Subject _subject){
    this.subject = _subject;
}

你要代理谁就产生该代理的实例，然后把被代理者传递进来，该模式在实际的项目应用中比较广泛。

发表于 更新于 分类于 ， ， Waline： 本文字数： 6k 阅读时长 ≈ 5 分钟

13.1 个性化电子账单

现在电子账单越来越流行了，比如你的信用卡，每到月初的时候银行就会发一份电子邮件给你，说你这个月消费了多少，什么时候消费的，积分是多少等，这是每个月发一次。还有一种也是银行发的邮件你肯定非常有印象：广告信，现在各大银行的信用卡部门都在拉拢客户，电子邮件是一种廉价、快捷的通信方式，你用纸质的广告信那个费用多高呀，比如我行今天推出一个信用卡刷卡抽奖活动，通过电子账单系统可以一个晚上发送给600万客户， 为什么要用电子账单系统呢？直接找个发垃圾邮件的工具不就解决问题了吗？是个好主意， 但是这个方案在金融行业是行不通的，为什么？因为银行发送该类邮件是有要求的：

  • 个性化服务

一般银行都要求个性化服务，发过去的邮件上总有一些个人信息吧，比如“××先 生”，“××女士”等。

  • 递送成功率

邮件的递送成功率有一定的要求，由于大批量地发送邮件会被接收方邮件服务器误认是垃圾邮件，因此在邮件头要增加一些伪造数据，以规避被反垃圾邮件引擎误认为是垃圾邮件。

从这两方面考虑广告信的发送也是电子账单系统（电子账单系统一般包括：账单分析、 账单生成器、广告信管理、发送队列管理、发送机、退信处理、报表管理等）的一个子功能，我们今天就来考虑一下广告信这个模块是怎么开发的。那既然是广告信，肯定需要一个模板，然后再从数据库中把客户的信息一个一个地取出，放到模板中生成一份完整的邮件， 然后扔给发送机进行发送处理，类图如图13-1所示。

在类图中AdvTemplate是广告信的模板，一般都是从数据库取出，生成一个BO或者是DTO，我们这里使用一个静态的值来作代表；Mail类是一封邮件类，发送机发送的就是这个类。我们先来看AdvTemplate，如代码清单13-1所示。

image-20210928190441572

图13-1 发送电子账单类图

代码清单13-1 广告信模板代码

1
2
3
4
5
6
7
8
9
10
11
12
13
14
public class AdvTemplate {
    //广告信名称
    private String advSubject ="XX银行国庆信用卡抽奖活动";
    //广告信内容
    private String advContext = "国庆抽奖活动通知：只要刷卡就送你一百万！...";
    //取得广告信的名称
    public String getAdvSubject(){
        return this.advSubject;
    }
    //取得广告信的内容
    public String getAdvContext(){
        return this.advContext;
    }
}

邮件类Mail如代码清单13-2所示。

代码清单13-2 邮件类代码

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
public class Mail {
    //收件人
    private String receiver;
    //邮件名称
    private String subject;
    //称谓
    private String appellation;
    //邮件内容
    private String contxt;
    //邮件的尾部，一般都是加上"XXX版权所有"等信息 private String tail;
    //构造函数
    public Mail(AdvTemplate advTemplate){
        this.contxt = advTemplate.getAdvContext();
        this.subject = advTemplate.getAdvSubject();
    }
    //以下为getter/setter方法 
    public String getReceiver() {
        return receiver;
    }
    public void setReceiver(String receiver) {
        this.receiver = receiver;
    }
    public String getSubject() {
        return subject;
    }
    public void setSubject(String subject) {
        this.subject = subject;
    }
    public String getAppellation() {
        return appellation;
    }
    public void setAppellation(String appellation) {
        this.appellation = appellation;
    }
    public String getContxt() {
        return contxt;
    }
    public void setContxt(String contxt) {
        this.contxt = contxt;
    }
    public String getTail() {
        return tail;
    }
    public void setTail(String tail) {
        this.tail = tail;
    }
}

Mail类就是一个业务对象，虽然比较长，还是比较简单的。我们再来看业务场景类是如何对邮件继续处理的，如代码清单11-3所示。

代码清单13-3 场景类

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
public class Client {
    //发送账单的数量，这个值是从数据库中获得
    private static int MAX_COUNT = 6;
    public static void main(String[] args) {
        //模拟发送邮件
        int i=0;
        //把模板定义出来，这个是从数据库中获得
        Mail mail = new Mail(new AdvTemplate());
        mail.setTail("XX银行版权所有");
        while(i<MAX_COUNT){
            //以下是每封邮件不同的地方
            mail.setAppellation(getRandString(5)+" 先生（女士）");
            mail.setReceiver(getRandString(5)+"@"+getRandString(8) +".com");
            //然后发送邮件
            sendMail(mail);
            i++;
        }
    }
    //发送邮件
    public static void sendMail(Mail mail){
        System.out.println("标题："+mail.getSubject() + "\t收件人： "+mail.getReceiver()+"\t...发送成功！");
    }
    //获得指定长度的随机字符串
    public static String getRandString(int maxLength){
        String source ="abcdefghijklmnopqrskuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ";
        StringBuffer sb = new StringBuffer();
        Random rand = new Random();
        for(int i=0;i<maxLength;i++){
            sb.append(source.charAt(rand.nextInt(source.length())));
        }
        return sb.toString();
    }
}

运行结果如下所示：

1
2
3
4
5
6
标题：XX银行国庆信用卡抽奖活动 收件人：fjQUm@ZnkyPSsL.com ...发送成功！ 
标题：XX银行国庆信用卡抽奖活动 收件人：ZIKnC@NOKdloNM.com ...发送成功！ 
标题：XX银行国庆信用卡抽奖活动 收件人：zNkMI@HpMMSZaz.com ...发送成功！ 
标题：XX银行国庆信用卡抽奖活动 收件人：oMTFA@uBwkRjxa.com ...发送成功！ 
标题：XX银行国庆信用卡抽奖活动 收件人：TquWT@TLLVNFja.com ...发送成功！ 
标题：XX银行国庆信用卡抽奖活动 收件人：rkQbp@mfATHDQH.com ...发送成功！

由于是随机数，每次运行都有所差异，不管怎么样，我们这个电子账单发送程序是编写出来了，也能正常发送。我们再来仔细地想想，这个程序是否有问题？Look here，这是一个线程在运行，也就是你发送的是单线程的，那按照一封邮件发出去需要0.02秒（够小了，你还要到数据库中取数据呢），600万封邮件需要33个小时，也就是一个整天都发送不完，今天的没发送完，明天的账单又产生了，日积月累，激起甲方人员一堆抱怨，那怎么办？

好办，把sendMail修改为多线程，但是只把sendMail修改为多线程还是有问题的呀，产生第一封邮件对象，放到线程1中运行，还没有发送出去；线程2也启动了，直接就把邮件对象mail的收件人地址和称谓修改掉了，线程不安全了。说到这里，你会说这有N多种解决办法，其中一种是使用一种新型模式来解决这个问题：通过对象的复制功能来解决这个问题， 类图稍做修改，如图13-2所示。

image-20210928190854417

图13-2 修改后的发送电子账单类图

增加了一个Cloneable接口（Java自带的一个接口）， Mail实现了这个接口，在Mail类中覆写clone()方法，我们来看Mail类的改变，如代码清单13-4所示。

代码清单13-4 修改后的邮件类

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
public class Mail implements Cloneable{
    //收件人
    private String receiver;
    //邮件名称
    private String subject;
    //称谓
    private String appellation;
    //邮件内容
    private String contxt;
    //邮件的尾部，一般都是加上"XXX版权所有"等信息 private String tail;
    //构造函数
    public Mail(AdvTemplate advTemplate){
        this.contxt = advTemplate.getAdvContext();
        this.subject = advTemplate.getAdvSubject();
    }
    @Override public Mail clone(){
        Mail mail =null;
        try {
            mail = (Mail)super.clone();
        }
        catch (CloneNotSupportedException e) {
            // TODO Auto-generated catch block e.printStackTrace();
        }
        return mail;
    }
    //以下为getter/setter方法 public String getReceiver() {
        return receiver;
    }
    public void setReceiver(String receiver) {
        this.receiver = receiver;
    }
    public String getSubject() {
        return subject;
    }
    public void setSubject(String subject) {
        this.subject = subject;
    }
    public String getAppellation() {
        return appellation;
    }
    public void setAppellation(String appellation) {
        this.appellation = appellation;
    }
    public String getContxt() {
        return contxt;
    }
    public void setContxt(String contxt) {
        this.contxt = contxt;
    }
    public String getTail() {
        return tail;
    }
    public void setTail(String tail) {
        this.tail = tail;
    }
}

注意看粗体部分，实现了一个接口，并重写了clone方法，大家可能看着这个类有点奇怪，先保留你的好奇，我们继续讲下去，稍后会给你清晰的答案。我们再来看场景Client的变化，如代码清单13-5所示。

代码清单13-5 修改后的场景类

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
public class Client {
    //发送账单的数量，这个值是从数据库中获得
    private static int MAX_COUNT = 6;
    public static void main(String[] args) {
        //模拟发送邮件
        int i=0;
        //把模板定义出来，这个是从数据中获得
        Mail mail = new Mail(new AdvTemplate());
        mail.setTail("XX银行版权所有");
        while(i<MAX_COUNT){
            //以下是每封邮件不同的地方
            Mail cloneMail = mail.clone();
            cloneMail.setAppellation(getRandString(5)+" 先生（女士）");
            cloneMail.setReceiver(getRandString(5)+"@"+getRandString(8)+".com");
            //然后发送邮件
            sendMail(cloneMail);
            i++;
        }
    }
}

运行结果不变，一样完成了电子广告信的发送功能，而且sendMail即使是多线程也没有关系。注意，看Client类中的粗体字mail.clone()这个方法，把对象复制一份，产生一个新的对象，和原有对象一样，然后再修改细节的数据，如设置称谓、设置收件人地址等。这种不通过new关键字来产生一个对象，而是通过对象复制来实现的模式就叫做原型模式。

发表于 更新于 分类于 ， ， Waline： 本文字数： 1.1k 阅读时长 ≈ 1 分钟

13.2 原型模式的定义

原型模式（Prototype Pattern）的简单程度仅次于单例模式和迭代器模式。正是由于简单，使用的场景才非常地多，其定义如下：

Specify the kinds of objects to create using a prototypical instance,and create new objects by copying this prototype.（用原型实例指定创建对象的种类，并且通过拷贝这些原型创建新的对象。）

原型模式的通用类图如图13-3所示。

image-20210928191309540

图13-3 原型模式的通用类图

简单，太简单了！原型模式的核心是一个clone方法，通过该方法进行对象的拷贝，Java 提供了一个Cloneable接口来标示这个对象是可拷贝的，为什么说是“标示”呢？翻开JDK的帮助看看Cloneable是一个方法都没有的，这个接口只是一个标记作用，在JVM中具有这个标记的对象才有可能被拷贝。那怎么才能从“有可能被拷贝”转换为“可以被拷贝”呢？方法是覆盖clone()方法，是的，你没有看错是重写clone()方法，看看我们上面Mail类中的clone方法，如代码清单13-6所示。

代码清单13-6 邮件类中的clone方法

1
2
@Override public Mail clone(){
}

注意，在clone()方法上增加了一个注解@Override，没有继承一个类为什么可以覆写呢？想想看，在Java中所有类的老祖宗是谁？对嘛，Object类，每个类默认都是继承了这个类，所以用覆写是非常正确的——覆写了Object类中的clone方法！

在Java中原型模式是如此简单，我们来看通用源代码，如代码清单13-7所示。

代码清单13-7 原型模式通用源码

1
2
3
4
5
6
7
8
9
10
11
12
13
public class PrototypeClass implements Cloneable{
    //覆写父类Object方法
    @Override public PrototypeClass clone(){
        PrototypeClass prototypeClass = null;
        try {
            prototypeClass = (PrototypeClass)super.clone();
        }
        catch (CloneNotSupportedException e) {
            //异常处理
        }
        return prototypeClass;
    }
}

实现一个接口，然后重写clone方法，就完成了原型模式！

发表于 更新于 分类于 ， ， Waline： 本文字数： 2.7k 阅读时长 ≈ 2 分钟

14.2 中介者模式的定义

中介者模式的定义为：Define an object that encapsulates how a set of objects interact.Mediator promotes loose coupling by keeping objects from referring to each other explicitly,and it lets you vary their interaction independently.（用一个中介对象封装一系列的对象 交互，中介者使各对象不需要显示地相互作用，从而使其耦合松散，而且可以独立地改变它 们之间的交互。）

中介者模式通用类图如图14-7所示。

image-20210928205435846

图14-7 中介者模式通用类图

从类图中看，中介者模式由以下几部分组成：

  • Mediator 抽象中介者角色

抽象中介者角色定义统一的接口，用于各同事角色之间的通信。

  • Concrete Mediator 具体中介者角色

具体中介者角色通过协调各同事角色实现协作行为，因此它必须依赖于各个同事角色。

  • Colleague 同事角色

每一个同事角色都知道中介者角色，而且与其他的同事角色通信的时候，一定要通过中介者角色协作。每个同事类的行为分为两种：一种是同事本身的行为，比如改变对象本身的状态，处理自己的行为等，这种行为叫做自发行为（Self-Method），与其他的同事类或中介者没有任何的依赖；第二种是必须依赖中介者才能完成的行为，叫做依赖方法（Dep-Method）。

中介者模式比较简单，其通用源码也比较简单，先看抽象中介者Mediator类，如代码清单14-12所示。

代码清单14-12 通用抽象中介者

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
public abstract class Mediator {
    //定义同事类
    protected ConcreteColleague1 c1;
    protected ConcreteColleague2 c2;
    //通过getter/setter方法把同事类注入进来
    public ConcreteColleague1 getC1() {
        return c1;
    }
    public void setC1(ConcreteColleague1 c1) {
        this.c1 = c1;
    }
    public ConcreteColleague2 getC2() {
        return c2;
    }
    public void setC2(ConcreteColleague2 c2) {
        this.c2 = c2;
    }
    //中介者模式的业务逻辑
    public abstract void doSomething1();
    public abstract void doSomething2();
}

在Mediator抽象类中我们只定义了同事类的注入，为什么使用同事实现类注入而不使用抽象类注入呢？那是因为同事类虽然有抽象，但是没有每个同事类必须要完成的业务方法， 当然如果每个同事类都有相同的方法，比如execute、handler等，那当然注入抽象类，做到依赖倒置。

具体的中介者一般只有一个，即通用中介者，其源代码如代码清单14-13所示。

代码清单14-13 通用中介者

1
2
3
4
5
6
7
8
9
10
11
public class ConcreteMediator extends Mediator {
    @Override public void doSomething1() {
        //调用同事类的方法，只要是public方法都可以调用
        super.c1.selfMethod1();
        super.c2.selfMethod2();
    }
    public void doSomething2() {
        super.c1.selfMethod1();
        super.c2.selfMethod2();
    }
}

中介者所具有的方法doSomething1和doSomething2都是比较复杂的业务逻辑，为同事类服务，其实现是依赖各个同事类来完成的。

同事类的基类如代码清单14-14所示。

代码清单14-14 抽象同事类

1
2
3
4
5
6
public abstract class Colleague {
    protected Mediator mediator;
    public Colleague(Mediator _mediator){
        this.mediator = _mediator;
    }
}

这个基类也非常简单。一般来说，中介者模式中的抽象都比较简单，是为了建立这个中介而服务的，具体同事类如代码清单14-15所示。

代码清单14-15 具体同事类

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
public class ConcreteColleague1 extends Colleague {
    //通过构造函数传递中介者
    public ConcreteColleague1(Mediator _mediator){
        super(_mediator);
    }
    //自有方法
    self-method public void selfMethod1(){
        //处理自己的业务逻辑
    }
    //依赖方法
    dep-method public void depMethod1(){
        //处理自己的业务逻辑
        //自己不能处理的业务逻辑，委托给中介者处理
        super.mediator.doSomething1();
    }
}
public class ConcreteColleague2 extends Colleague {
    //通过构造函数传递中介者
    public ConcreteColleague2(Mediator _mediator){
        super(_mediator);
    }
    //自有方法
    self-method public void selfMethod2(){
        //处理自己的业务逻辑
    }
    //依赖方法
    dep-method public void depMethod2(){
        //处理自己的业务逻辑
        //自己不能处理的业务逻辑，委托给中介者处理
        super.mediator.doSomething2();
    }
}

为什么同事类要使用构造函数注入中介者，而中介者使用getter/setter方式注入同事类呢？这是因为同事类必须有中介者，而中介者却可以只有部分同事类。

发表于 更新于 分类于 ， ， Waline： 本文字数： 7.2k 阅读时长 ≈ 7 分钟

15.1 项目经理也难当

我是公司的项目经理，在国内做项目，项目经理需要什么都懂，什么都管。做好了，项目经理能分到一杯羹；做不好，都是项目经理的责任。这几乎是绝对的，我带过很多项目， 行政命令一压下来，那就一条道：做完做好！

虽然我们公司是一个集团公司，但是我们部门的业绩是独立核算的，也就是说，我们部门不仅可以为集团公司服务，还可以为其他甲方服务，赚取更多的外快。2007年，我曾负责一个比较小的项目（但是项目的合同金额可不少）——为某家旅行社建立一套内部管理系统。该旅行社的门店比较多，员工也比较多，这个内部管理系统用来管理客户、旅游资源、 票务以及内部事务，整体上类似于一个小型的MIS系统。客户的需求比较明确，因为他们曾经自己购买了一套内部管理系统，这次变动基本上是翻版；而且这家旅行社也有自己的IT部门，技术人员之间语言相通，比较好相处，也没有交流鸿沟。

该项目的成员分工采用了常规的分工方式，分为需求组（Requirement Group,RG）、美工组（Page Group,PG）、代码组（我们内部还有一个比较优雅的名字：逻辑实现组，这里使用大家经常称呼的名称，即Code Group，简称CG），加上我这个项目经理正好十个人。刚开始，客户（也就是旅行社，甲方）很乐意和我们每个组探讨，比如和需求组讨论需求、和美工讨论页面、和代码组讨论实现，告诉他们修改、删除、增加各种内容等。这是一种比较常见的甲乙方合作模式，甲方深入到乙方的项目开发中，我们可以使用类图来表示这个过程，如图15-1所示。

image-20210928212436694

图15-1 旅行社项目开发过程类图

这个类图很简单，客户和三个组都有交流，这也合情合理。那我们看看这个过程的实现，首先看抽象类Group，如代码清单15-1所示。

代码清单15-1 抽象组

1
2
3
4
5
6
7
8
9
10
11
12
public abstract class Group {
    //甲乙双方分开办公，如果你要和某个组讨论，你首先要找到这个组
    public abstract void find();
    //被要求增加功能
    public abstract void add();
    //被要求删除功能
    public abstract void delete();
    //被要求修改功能
    public abstract void change();
    //被要求给出所有的变更计划
    public abstract void plan();
}

大家看抽象类中的每个方法，其中的每个都是一个命令语气——“找到它，增加，删除，给我计划！”这些都是命令，给出命令然后由相关的人员去执行。我们再看3个实现类， 其中的需求组最重要，需求组RequirmentGroup类如代码清单15-2所示。

代码清单15-2 需求组

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
public class RequirementGroup extends Group {
    //客户要求需求组过去和他们谈
    public void find() {
        System.out.println("找到需求组...");
    }
    //客户要求增加一项需求
    public void add() {
        System.out.println("客户要求增加一项需求...");
    }
    //客户要求修改一项需求
    public void change() {
        System.out.println("客户要求修改一项需求...");
    }
    //客户要求删除一项需求
    public void delete() {
        System.out.println("客户要求删除一项需求...");
    }
    //客户要求给出变更计划
    public void plan() {
        System.out.println("客户要求需求变更计划...");
    }
}

需求组有了，我们再看美工组。美工组也很重要，是项目的脸面，客户最终接触到的还是界面。美工组PageGroup类如代码清单15-3所示。

代码清单15-3 美工组

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
public class PageGroup extends Group {
    //首先这个美工组应该能找到吧，要不你跟谁谈？
    public void find() {
        System.out.println("找到美工组...");
    }
    //美工被要求增加一个页面
    public void add() {
        System.out.println("客户要求增加一个页面...");
    }
    //客户要求对现有界面做修改
    public void change() {
        System.out.println("客户要求修改一个页面...");
        
    }
    //甲方是老大，要求删除一些页面
    public void delete() {
        System.out.println("客户要求删除一个页面...");
    }
    //所有的增、删、改都要给出计划
    public void plan() {
        System.out.println("客户要求页面变更计划...");
    }
}

最后看代码组。这个组的成员一般比较沉闷，不多说话，但多做事儿，这是这个组的典型特点。代码组CodeGroup类如代码清单15-4所示。

代码清单15-4 代码组

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
public class CodeGroup extends Group {
    //客户要求代码组过去和他们谈
    public void find() {
        System.out.println("找到代码组...");
    }
    //客户要求增加一项功能
    public void add() {
        System.out.println("客户要求增加一项功能...");
    }
    //客户要求修改一项功能
    public void change() {
        System.out.println("客户要求修改一项功能...");
    }
    //客户要求删除一项功能
    public void delete() {
        System.out.println("客户要求删除一项功能...");
    }
    //客户要求给出变更计划
    public void plan() {
        System.out.println("客户要求代码变更计划...");
    }
}

整个项目的3个支柱都已经产生了，那看客户怎么和我们谈。客户刚开始提交了他们自己写的一份比较完整的需求，需求组根据这份需求写了一份分析说明书，客户看后，要求增加需求，该场景如代码清单15-5所示。

代码清单15-5 场景类

1
2
3
4
5
6
7
8
9
10
11
12
13
public class Client {
    public static void main(String[] args) {
        //首先客户找到需求组说，过来谈需求，并修改
        System.out.println("-----------客户要求增加一项需求---------------");
        Group rg = new RequirementGroup();
        //找到需求组
        rg.find();
        //增加一个需求
        rg.add();
        //要求变更计划
        rg.plan();
    }
}

运行的结果如下所示：

1
2
3
4
-------------客户要求增加一项需求----------------- 
找到需求组... 
客户要求增加一项需求... 
客户要求需求变更计划...

客户的需求暂时满足了，过了一段时间，客户又要求“界面多画了一个，过来谈谈”，于是又有一次场景变化，如代码清单15-6所示。

代码清单15-6 变化的场景类

1
2
3
4
5
6
7
8
9
10
11
12
13
public class Client {
    public static void main(String[] args) {
        //首先客户找到美工组说，过来谈页面，并修改
        System.out.println("----------客户要求删除一个页面--------------");
        Group pg = new PageGroup();
        //找到需求组
        pg.find();
        //删除一项需求
        pg.delete();
        //要求变更计划
        pg.plan();
    }
}

运行结果如下所示：

1
2
3
4
-------------客户要求删除一个页面----------------- 
找到美工组... 
客户要求删除一个页面... 
客户要求页面变更计划...

好了，界面也谈过了，应该没什么大问题了吧。过了一天后，客户又让代码组过去，说是数据库设计问题，然后又叫美工组过去，布置了一堆命令……这个就不一一写了，大家应该能够体会得到！问题来了，我们修改可以，但是每次都是叫一个组去，布置个任务，然后出计划，每次都这样，如果让你当甲方，你烦不烦？而且这种方式很容易出错误，并且还真发生过。客户把美工叫过去了，要删除，可美工说需求是这么写的，然后客户又命令需求组过去，一次次地折腾之后，客户也烦躁了，于是直接抓住我这个项目经理说：“我不管你们内部怎么安排，你就给我找个接头负责人，我告诉他怎么做，删除页面，增加功能，你们内部怎么处理我不管，我就告诉他我要干什么就成了……”

我一听，好啊，这也正是我想要的，我们项目组的兄弟们也已经受不了了，于是我改变了一下我的处理方式，如图15-2所示。

image-20210928213345960

图15-2 增加负责人后的类图

在原有的类图上增加了一个Invoker类，其作用是根据客户的命令安排不同的组员进行工作，例如，客户说“界面上删除一条记录”，Invoker类接收到该String类型命令后，通知美工组PageGroup开始delete，然后再找到代码组CodeGroup后台不要存到数据库中，最后反馈给客户一个执行计划。这是一个挺好的方案，但是客户的命令是一个String类型的，这有非常多的变化，仅仅通过一个字符串来传递命令并不是一个非常好的方案，因为在系统设计中， 字符串没有约束力，根据字符串判断相关的业务逻辑不是一个优秀的解决方案。那怎么才是一个优秀的方案呢？解决方案是：对客户发出的命令进行封装，每个命令是一个对象，避免客户、负责人、组员之间的交流误差，封装后的结果就是客户只要说一个命令，我的项目组就立刻开始启动，不用思考、解析命令字符串，如图15-3所示。

image-20210928213515332

图15-3 完美的类图

Command抽象类只有一个方法execute，其作用就是执行命令，子类非常坚决地实现该命令，与军队中类似，上级军官给士兵发布命令：爬上这个旗杆！然后士兵回答：Yes,Sir！完美的项目也与此类似，客户发送一个删除页面的命令，接头负责人Invoker接收到命令后，立刻执行DeletePageCommand的execute方法。对类图中增加的几个类说明如下。

  • Command抽象类：客户发给我们的命令，定义三个工作组的成员变量，供子类使用； 定义一个抽象方法execute，由子类来实现。
  • CInvoker实现类：项目接头负责人，setComand接收客户发给我们的命令，action方法是执行客户的命令（方法名写成是action，与command的execute区分开，避免混淆）。

其中，Command抽象类是整个扩展的核心，其源代码如代码清单15-7所示。

代码清单15-7 抽象命令类

1
2
3
4
5
6
7
8
9
10
11
public abstract class Command {
    //把三个组都定义好，子类可以直接使用
    protected RequirementGroup rg = new RequirementGroup();
    //需求组
    protected PageGroup pg = new PageGroup();
    //美工组
    protected CodeGroup cg = new CodeGroup();
    //代码组
    //只有一个方法，你要我做什么事情
    public abstract void execute();
}

抽象类很简单，具体的实现类只要实现execute方法就可以了。在一个项目中，需求增加是很常见的，那就把“增加需求”定义为一个命令AddRequirementCommand类，如代码清单15- 8所示。

代码清单15-8 增加需求的命令

1
2
3
4
5
6
7
8
9
10
11
public class AddRequirementCommand extends Command {
    //执行增加一项需求的命令
    public void execute() {
        //找到需求组
        super.rg.find();
        //增加一份需求
        super.rg.add();
        //给出计划
        super.rg.plan();
    }
}

页面变更也是比较频繁发生的，定义一个删除页面的命令DeletePageCommand类，如代码清单15-9所示。

代码清单15-9 删除页面的命令

1
2
3
4
5
6
7
8
9
10
11
public class DeletePageCommand extends Command {
    //执行删除一个页面的命令
    public void execute() {
        //找到页面组
        super.pg.find();
        //删除一个页面
        super.rg.delete();
        //给出计划
        super.rg.plan();
    }
}

Command抽象类可以有N个子类，如增加一个功能命令（AddFunCommand），删除一份需求命令（DeleteRequirementCommand）等，这里就不再描述了，只要是由客户产生、时常性的行为都可以定义为一个命令，其实现类都比较简单，读者可以自行扩展。

客户发送的命令已经确定下来，我们再看负责人Invoker，如代码清单15-10所示。

代码清单15-10 负责人

1
2
3
4
5
6
7
8
9
10
11
12
public class Invoker {
    //什么命令
    private Command command;
    //客户发出命令
    public void setCommand(Command command){
        this.command = command;
    }
    //执行客户的命令
    public void action(){
        this.command.execute();
    }
}

这更简单了，负责人只要接到客户的命令，就立刻执行。我们模拟增加一项需求的过程，如代码清单15-11所示。

代码清单15-11 增加一项需求

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
public class Client {
    public static void main(String[] args) {
        //定义我们的接头人
        Invoker xiaoSan = new Invoker();
        //接头人就是小三
        //客户要求增加一项需求
        System.out.println("------------客户要求增加一项需求---------------");
        //客户给我们下命令来
        Command command = new AddRequirementCommand();
        //接头人接收到命令
        xiaoSan.setCommand(command);
        //接头人执行命令
        xiaoSan.action();
    }
}

运行结果如下所示：

1
2
3
4
-------------客户要求增加一项需求----------------- 
找到需求组... 
客户要求增加一项需求... 
客户要求需求变更计划...

是不是我们的场景类简单了很多？客户只要给命令，我马上执行。简单！非常简单！那我们看看，如果客户要求删除一个页面，我们的修改有多大，如代码清单15-12所示。

代码清单15-12 删除一个页面

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
public class Client {
    public static void main(String[] args) {
        //定义我们的接头人
        Invoker xiaoSan = new Invoker();
        //接头人就是小三
        //客户要求增加一项需求
        System.out.println("------------客户要求删除一个页面---------------");
        //客户给我们下命令来
        //Command command = new AddRequirementCommand();
        Command command = new DeletePageCommand();
        //接头人接收到命令
        xiaoSan.setCommand(command);
        //接头人执行命令
        xiaoSan.action();
    }
}

运行结果如下所示：

1
2
3
4
-------------客户要求删除一个页面----------------- 
找到美工组... 
客户要求删除一项需求... 
客户要求需求变更计划...

看到上面用粗体显示的代码了吗？只修改了这么多，是不是很简单，而且客户也不用知道到底由谁来修改，高内聚的要求体现出来了，这就是命令模式。

发表于 更新于 分类于 ， ， Waline： 本文字数： 3k 阅读时长 ≈ 3 分钟

16.2 责任链模式的定义

责任链模式定义如下：

Avoid coupling the sender of a request to its receiver by giving more than one object a chance to handle the request.Chain the receiving objects and pass the request along the chain until an object handles it.（使多个对象都有机会处理请求，从而避免了请求的发送者和接受者之间的耦合关系。将这些对象连成一条链，并沿着这条链传递该请求，直到有对象处理它为止。）

责任链模式的重点是在“链”上，由一条链去处理相似的请求在链中决定谁来处理这个请求，并返回相应的结果，其通用类图如图16-4所示。

image-20210929113427126

图16-4 责任链模式通用类图

责任链模式的核心在“链”上，“链”是由多个处理者ConcreteHandler组成的，我们先来看抽象Handler类，如代码清单16-14所示。

代码清单16-14 抽象处理者

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
public abstract class Handler {
    private Handler nextHandler;
    //每个处理者都必须对请求做出处理
    public final Response handleMessage(Request request){
        Response response = null;
        //判断是否是自己的处理级别
        if(this.getHandlerLevel().equals(request.getRequestLevel())){
            response = this.echo(request);
        }
        else{
            //不属于自己的处理级别
            //判断是否有下一个处理者
            if(this.nextHandler != null){
                response = this.nextHandler.handleMessage(request);
            }
            else{
                //没有适当的处理者，业务自行处理
            }
        }
        return response;
    }
    //设置下一个处理者是谁
    public void setNext(Handler _handler){
        this.nextHandler = _handler;
    }
    //每个处理者都有一个处理级别
    protected abstract Level getHandlerLevel();
    //每个处理者都必须实现处理任务
    protected abstract Response echo(Request request);
}

抽象的处理者实现三个职责：一是定义一个请求的处理方法handleMessage，唯一对外开放的方法；二是定义一个链的编排方法setNext，设置下一个处理者；三是定义了具体的请求者必须实现的两个方法：定义自己能够处理的级别getHandlerLevel和具体的处理任务echo。

注意 在责任链模式中一个请求发送到链中后，前一节点消费部分消息，然后交由后续节点继续处理，最终可以有处理结果也可以没有处理结果，读者可以不用理会什么纯的、不纯的责任链模式。同时，请读者注意handlerMessage方法前的final关键字，可以阅读第10章的模板方法模式。

我们定义三个具体的处理者，以便可以组成一个链，如代码清单16-15所示。

代码清单16-15 具体处理者

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
public class ConcreteHandler1 extends Handler {
    //定义自己的处理逻辑
    protected Response echo(Request request) {
        //完成处理逻辑
        return null;
        
    }
    //设置自己的处理级别
    protected Level getHandlerLevel() {
        //设置自己的处理级别
        return null;
    }
}
public class ConcreteHandler2 extends Handler {
    //定义自己的处理逻辑
    protected Response echo(Request request) {
        //完成处理逻辑
        return null;
    }
    //设置自己的处理级别
    protected Level getHandlerLevel() {
        //设置自己的处理级别
        return null;
    }
}
public class ConcreteHandler3 extends Handler {
    //定义自己的处理逻辑
    protected Response echo(Request request) {
        //完成处理逻辑
        return null;
    }
    //设置自己的处理级别
    protected Level getHandlerLevel() {
        //设置自己的处理级别
        return null;
    }
}

在处理者中涉及三个类：Level类负责定义请求和处理级别，Request类负责封装请求，Response负责封装链中返回的结果，该三个类都需要根据业务产生，读者可以在实际应用中完成相关的业务填充，其框架代码如代码清单16-16所示。

代码清单16-16 模式中有关框架代码

1
2
3
4
5
6
7
8
9
10
11
12
public class Level {
    //定义一个请求和处理等级
}
public class Request {
    //请求的等级
    public Level getRequestLevel(){
        return null;
    }
}
public class Response {
    //处理者返回的数据
}

在场景类或高层模块中对链进行组装，并传递请求，返回结果，如代码清单16-17所示。

代码清单16-17 场景类

1
2
3
4
5
6
7
8
9
10
11
12
13
public class Client {
    public static void main(String[] args) {
        //声明所有的处理节点
        Handler handler1 = new ConcreteHandler1();
        Handler handler2 = new ConcreteHandler2();
        Handler handler3 = new ConcreteHandler3();
        //设置链中的阶段顺序1-->2-->3
        handler1.setNext(handler2);
        handler2.setNext(handler3);
        //提交请求，返回结果
        Response response = handler1.handlerMessage(new Request());
    }
}

在实际应用中，一般会有一个封装类对责任模式进行封装，也就是替代Client类，直接返回链中的第一个处理者，具体链的设置不需要高层次模块关系，这样，更简化了高层次模块的调用，减少模块间的耦合，提高系统的灵活性。