19.1 业务发展——上帝才能控制

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

19.1 业务发展——上帝才能控制

有这样一句名言：“智者千虑必有一失，愚者千虑必有一得”^1，意思是说不管多聪明的人，经过多少次的思考，也总是会出现一些微小的错误，“智者”都是如此，何况我们这些平庸之辈呢！我们在进行系统开发时，不管之前的可行性分析、需求分析、系统设计处理得多么完美，总会在关键时候、关键场合出现一些“意外”。对于这些“意外”，该来的还是要来， 躲是躲不过去的，那我们怎么来弥补这些“意外”呢？这难不倒我们的设计大师，他们创造出了一些补救模式，今天我们就来讲一个补救模式，这种模式可以让你从因业务扩展而系统无法迅速适应的苦恼中解脱而出。

2004年我带了一个项目，做一个人力资源管理项目，该项目是我们总公司发起的，公司一共有700多号人。这个项目还是比较简单的，分为三大模块：人员信息管理、薪酬管理、 职位管理。当时开发时业务人员明确指明：人员信息管理的对象是所有员工的所有信息，所有的员工指的是在职的员工，其他的离职的、退休的暂不考虑。根据需求我们设计了如图19-1所示的类图。

image-20210929155745649

图19-1 人员信息类图

非常简单，有一个对象UserInfo存储用户的所有信息（实际系统上还有很多子类，不多说了），也就是BO（Business Object，业务对象），这个对象设计为贫血对象（Thin Business Object），不需要存储状态以及相关的关系，本人是反对使用充血对象（Rich Business Object），这里提到两个名词：贫血对象和充血对象，这两个名词很简单，在领域模型中分别叫做贫血领域模型和充血领域模型，有什么区别呢？一个对象如果不存储实体状态以及对象之间的关系，该对象就叫做贫血对象，对应的领域模型就是贫血领域模型，有实体状态和对象关系的模型就是充血领域模型。看不懂没关系，都是糊弄人的东西，属于专用名词。扯远了，我们继续说我们的人力资源管理项目，这个UserInfo对象，在系统中很多地方使用，你可以查看自己的信息，也可以修改，当然这个对象是有setter方法的，我们这里用不到就隐藏掉了。先来看接口，员工信息接口如代码清单19-1所示。

代码清单19-1 员工信息接口

1
2
3
4
5
6
7
8
9
10
11
12
13
14
public interface IUserInfo {
    //获得用户姓名
    public String getUserName();
    //获得家庭地址
    public String getHomeAddress();
    //手机号码，这个太重要，手机泛滥呀
    public String getMobileNumber();
    //办公电话，一般是座机
    public String getOfficeTelNumber();
    //这个人的职位是什么
    public String getJobPosition();
    //获得家庭电话，这有点不好，我不喜欢打家庭电话讨论工作
    public String getHomeTelNumber();
}

员工信息接口有了，就需要设计一个实现类来容纳数据，如代码清单19-2所示。

代码清单19-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
public class UserInfo implements IUserInfo {
    /*
    * 获得家庭地址，下属送礼也可以找到地方 
    */ 
    public String getHomeAddress() {
        System.out.println("这里是员工的家庭地址...");
        return null;
    }
    /*
    * 获得家庭电话号码 
    */ 
    public String getHomeTelNumber() {
        System.out.println("员工的家庭电话是...");
        return null;
    }
    /*
    * 员工的职位，是部门经理还是普通职员 
    */ 
    public String getJobPosition() {
        System.out.println("这个人的职位是BOSS...");
        return null;
    }
    /*
    * 手机号码 
    */ 
    public String getMobileNumber() {
        System.out.println("这个人的手机号码是0000...");
        return null;
    }
    /*
    * 办公室电话，烦躁的时候最好"不小心"把电话线踢掉 
    */ 
    public String getOfficeTelNumber() {
        System.out.println("办公室电话是...");
        return null;
    }
    /*
    * 姓名，这个很重要 
    */ 
    public String getUserName() {
        
        System.out.println("姓名叫做...");
        return null;
    }
}

这个项目是2004年年底投产的，运行到2005年年底还是比较平稳的，中间修修补补也很正常，2005年年底不知道是哪股风吹的，很多公司开始使用借聘人员的方式引进人员，我们公司也不例外，从一个劳动资源公司借用了一大批的低技术、低工资的人员，分配到各个子公司，总共有将近200人，然后人力资源部就找我们部门老大谈判，说要增加一个功能：借用人员管理，老大一看有钱赚呀，一拍大腿，做！

老大命令一下来，我立马带人过去调研，需求就一句话，但是真深入地调研还真不是那么简单。借聘人员虽然在我们公司干活，和我们一个样，干活时没有任何的差别，但是他们的人员信息、工资情况、福利情况等都是由劳动服务公司管理的，并且有一套自己的人员管理系统，人力资源部门就要求我们系统同步劳动服务公司的信息，当然是只要在我们公司工作的人员信息，其他人员信息是不需要的，而且还要求信息同步，也就是：劳动服务公司的人员信息一变更，我们系统就应该立刻体现出来，为什么要即时而不批量呢？是因为我们公司与劳动服务公司之间是按照人头收费的，甭管是什么人，只要我们公司借用，就这个价格，我要一个研究生，你派了一个高中生给我，那算什么事？因此，了解了业务需求用后， 项目组决定采用RMI（Remote Method Invocation，远程对象调用）的方式进行联机交互，但是深入分析后，一个重大问题立刻显现出来：劳动服务公司的人员对象和我们系统的对象不相同，他们的对象如下所示。

image-20210929160052594

图19-2 劳动服务公司的人员信息类图

劳动服务公司是把人员信息分为了三部分：基本信息、办公信息和个人家庭信息，并且都放到了HashMap中，比如人员的姓名放到BaseInfo信息中，家庭地址放到HomeInfo中，这也是一个可以接受的模式，我们来看看他们的代码，接口如代码清单19-3所示。

代码清单19-3 劳动服务公司的人员信息接口

1
2
3
4
5
6
7
8
public interface IOuterUser {
    //基本信息，比如名称、性别、手机号码等
    public Map getUserBaseInfo();
    //工作区域信息
    public Map getUserOfficeInfo();
    //用户的家庭信息
    public Map getUserHomeInfo();
}

劳动服务公司的人员信息是这样存放的，如代码清单19-4所示。

代码清单19-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
public class OuterUser implements IOuterUser {
    /*
    * 用户的基本信息 
    */
    public Map getUserBaseInfo() {
        HashMap baseInfoMap = new HashMap();
        baseInfoMap.put("userName", "这个员工叫混世魔王...");
        baseInfoMap.put("mobileNumber", "这个员工电话是...");
        return baseInfoMap;
    }
    /*
    * 员工的家庭信息 
    */
    public Map getUserHomeInfo() {
        HashMap homeInfo = new HashMap();
        homeInfo.put("homeTelNumbner", "员工的家庭电话是...");
        homeInfo.put("homeAddress", "员工的家庭地址是...");
        return homeInfo;
    }
    /*
    * 员工的工作信息，比如，职位等 
    */
    public Map getUserOfficeInfo() {
        HashMap officeInfo = new HashMap();
        officeInfo.put("jobPosition","这个人的职位是BOSS...");
        officeInfo.put("officeTelNumber", "员工的办公电话是...");
        return officeInfo;
    }
}

看到这里，咱不好说他们系统设计得不好，问题是咱的系统要和他们的系统进行交互， 怎么办？我们不可能为了这一小小的功能而对我们已经运行良好系统进行大手术，那怎么办？我们可以转化，先拿到对方的数据对象，然后转化为我们自己的数据对象，中间加一层转换处理，按照这个思路，我们设计了如图19-3所示的类图。

image-20210929161402861

图19-3 增加了中转处理的人员信息类图

大家可能会问，这两个对象都不在一个系统中，你如何使用呢？简单！RMI已经帮我们做了这件事情，只要有接口，就可以把远程的对象当成本地的对象使用，这个大家有时间可以去看一下RMI文档，不多说了。OuterUserInfo可以看做是“两面派”，实现了IUserInfo接口， 还继承了OuterUser，通过这样的设计，把OuterUser伪装成我们系统中一个IUserInfo对象，这样，我们的系统基本不用修改，所有的人员查询、调用跟本地一样。

注意 我们之所以能够增加一个OuterUserInfo中转类，是因为我们在系统设计时严格遵守了依赖倒置原则和里氏替换原则，否则即使增加了中转类也无法解决问题。

说得口干舌燥，下边我们来看具体的代码实现，中转角色OuterUserInfo如代码清单19-5 所示。

代码清单19-5 中转角色

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 OuterUserInfo extends OuterUser implements IUserInfo {
    private Map baseInfo = super.getUserBaseInfo();
    //员工的基本信息
    private Map homeInfo = super.getUserHomeInfo();
    //员工的家庭信息
    private Map officeInfo = super.getUserOfficeInfo();
    //工作信息
    /*
    * 家庭地址 
    */
    public String getHomeAddress() {
        String homeAddress = (String)this.homeInfo.get("homeAddress");
        System.out.println(homeAddress);
        return homeAddress;
    }
    /*
    * 家庭电话号码 
    */
    public String getHomeTelNumber() {
        String homeTelNumber = (String)this.homeInfo.get("homeTelNumber");
        System.out.println(homeTelNumber);
        return homeTelNumber;
    }
    /*
    *职位信息 
    */
    public String getJobPosition() {
        String jobPosition = (String)this.officeInfo.get("jobPosition");
        System.out.println(jobPosition);
        return jobPosition;
    }
    /*
    * 手机号码 
    */
    public String getMobileNumber() {
        String mobileNumber = (String)this.baseInfo.get("mobileNumber");
        System.out.println(mobileNumber);
        return mobileNumber;
    }
    /*
    * 办公电话 
    */
    public String getOfficeTelNumber() {
        String officeTelNumber = (String)this.officeInfo.get("officeTelNumber");
        System.out.println(officeTelNumber);
        return officeTelNumber;
    }
    /*
    * 员工的名称 
    */
    public String getUserName() {
        String userName = (String)this.baseInfo.get("userName");
        System.out.println(userName);
        return userName;
    }
}

大家看到没？中转的角色有很多的强制类型转换，就是(String)这个东西，如果使用泛型的话，就可以完全避免这个转化（当然了，泛型当时还没有诞生）。我们要看看这个中转是否真的起到了中转的作用，我们想象这样一个场景：公司大老板想看看我们自己公司年轻女孩子的电话号码，那该场景类就如代码清单19-6所示。

代码清单19-6 场景类

1
2
3
4
5
6
7
8
9
10
public class Client {
    public static void main(String[] args) {
        //没有与外系统连接的时候，是这样写的
        IUserInfo youngGirl = new UserInfo();
        //从数据库中查到101个
        for(int i=0;i<101;i++){
            youngGirl.getMobileNumber();
        }
    }
}

这老板比较色呀。从数据库中生成了101个UserInfo对象，直接打印出来就成了。老板回头一想，不对呀，兔子不吃窝边草，还是调取借用人员看看，于是要查询出借用人员中美女的电话号码，如代码清单19-7所示。

代码清单19-7 查看劳动服务公司人员信息场景

1
2
3
4
5
6
7
8
9
10
11
public class Client {
    public static void main(String[] args) {
        //老板一想不对呀，兔子不吃窝边草，还是找借用人员好点
        //我们只修改了这句话
        IUserInfo youngGirl = new OuterUserInfo();
        //从数据库中查到101个
        for(int i=0;i<101;i++){
            youngGirl.getMobileNumber();
        }
    }
}

大家看，使用了适配器模式只修改了一句话，其他的业务逻辑都不用修改就解决了系统对接的问题，而且在我们实际系统中只是增加了一个业务类的继承，就实现了可以查本公司的员工信息，也可以查人力资源公司的员工信息，尽量少的修改，通过扩展的方式解决了该问题。这就是适配模式。