1700465921
设计模式之禅 [:1700454001]
1700465922
设计模式之禅 第19章 适配器模式
1700465923
1700465924
设计模式之禅 [:1700454002]
1700465925
19.1 业务发展——上帝才能控制
1700465926
1700465927
有这样一句名言“智者千虑必有一失，愚者千虑必有一得”[1]，意思是说不管多聪明的人，经过多少次的思考，也总是会出现一些微小的错误，“智者”都是如此，何况我们这些平庸之辈呢！我们在进行系统开发时，不管之前的可行性分析、需求分析、系统设计处理得多么完美，总会在关键时候、关键场合出现一些“意外”。对于这些“意外”，该来的还是要来，躲是躲不过去的，那我们怎么来弥补这些“意外”呢？这难不倒我们的设计大师，他们创造出了一些补救模式，今天我们就来讲一个补救模式，这种模式可以让你从因业务扩展而系统无法迅速适应的苦恼中解脱而出。
1700465928
1700465929
2004年我带了一个项目，做一个人力资源管理项目，该项目是我们总公司发起的，公司一共有700多号人。这个项目还是比较简单的，分为三大模块：人员信息管理、薪酬管理、职位管理。当时开发时业务人员明确指明：人员信息管理的对象是所有员工的所有信息，所有的员工指的是在职的员工，其他的离职的、退休的暂不考虑。根据需求我们设计了如图19-1所示的类图。
1700465930
1700465931
1700465932
1700465933
1700465934
图19-1 人员信息类图
1700465935
1700465936
非常简单，有一个对象UserInfo存储用户的所有信息（实际系统上还有很多子类，不多说了），也就是BO（Business Object，业务对象），这个对象设计为贫血对象（Thin Business Object），不需要存储状态以及相关的关系，本人是反对使用充血对象（Rich Business Object），这里提到两个名词：贫血对象和充血对象，这两个名词很简单，在领域模型中分别叫做贫血领域模型和充血领域模型，有什么区别呢？一个对象如果不存储实体状态以及对象之间的关系，该对象就叫做贫血对象，对应的领域模型就是贫血领域模型，有实体状态和对象关系的模型就是充血领域模型。看不懂没关系，都是糊弄人的东西，属于专用名词。扯远了，我们继续说我们的人力资源管理项目，这个UserInfo对象，在系统中很多地方使用，你可以查看自己的信息，也可以修改，当然这个对象是有setter方法的，我们这里用不到就隐藏掉了。先来看接口，员工信息接口如代码清单19-1所示。
1700465937
1700465938
代码清单19-1 员工信息接口
1700465939
1700465940
public interface IUserInfo{
1700465941
1700465942
//获得用户姓名
1700465943
1700465944
public String getUserName（）；
1700465945
1700465946
//获得家庭地址
1700465947
1700465948
public String getHomeAddress（）；
1700465949
1700465950
//手机号码，这个太重要，手机泛滥呀
1700465951
1700465952
public String getMobileNumber（）；
1700465953
1700465954
//办公电话，一般是座机
1700465955
1700465956
public String getOfficeTelNumber（）；
1700465957
1700465958
//这个人的职位是什么
1700465959
1700465960
public String getJobPosition（）；
1700465961
1700465962
//获得家庭电话，这有点不好，我不喜欢打家庭电话讨论工作
1700465963
1700465964
public String getHomeTelNumber（）；
1700465965
1700465966
}
1700465967
1700465968
员工信息接口有了，就需要设计一个实现类来容纳数据，如代码清单19-2所示。
1700465969
1700465970
代码清单19-2 实现类