1700454309
图1-1 用户信息维护类图
1700454310
1700454311
重新拆封成两个接口，IUserBO负责用户的属性，简单地说，IUserBO的职责就是收集和反馈用户的属性信息；IUserBiz负责用户的行为，完成用户信息的维护和变更。各位可能要说了，这个与我实际工作中用到的User类还是有差别的呀！别着急，我们先来看一看分拆成两个接口怎么使用。OK，我们现在是面向接口编程，所以产生了这个UserInfo对象之后，当然可以把它当IUserBO接口使用。也可以当IUserBiz接口使用，这要看你在什么地方使用了。要获得用户信息，就当是IUserBO的实现类；要是希望维护用户的信息，就把它当作IUserBiz的实现类就成了，如代码清单1-1所示。
1700454312
1700454313
1700454314
1700454315
1700454316
图1-2 职责划分后的类图
1700454317
1700454318
代码清单1-1 分清职责后的代码示例
1700454319
1700454320
……
1700454321
1700454322
IUserBiz userInfo=new UserInfo（）；
1700454323
1700454324
//我要赋值了，我就认为它是一个纯粹的BO
1700454325
1700454326
IUserBO userBO=（IUserBO）userInfo；
1700454327
1700454328
userBO.setPassword（“abc”）；
1700454329
1700454330
//我要执行动作了，我就认为是一个业务逻辑类
1700454331
1700454332
IUserBiz userBiz=（IUserBiz）userInfo；
1700454333
1700454334
userBiz.deleteUser（）；
1700454335
1700454336
……
1700454337
1700454338
确实可以如此，问题也解决了，但是我们来分析一下刚才的动作，为什么要把一个接口拆分成两个呢？其实，在实际的使用中，我们更倾向于使用两个不同的类或接口：一个是IUserBO，一个是IUserBiz，类图如图1-3所示。
1700454339
1700454340
以上我们把一个接口拆分成两个接口的动作，就是依赖了单一职责原则，那什么是单一职责原则呢？单一职责原则的定义是：应该有且仅有一个原因引起类的变更。
1700454341
1700454342
1700454343
1700454344
1700454345
图1-3 项目中经常采用的SRP类图
1700454346
1700454347
1700454348
1700454349
1700454350
设计模式之禅 [:1700453904]
1700454351
设计模式之禅 1.2 绝杀技，打破你的传统思维
1700454352
1700454353
解释到这里，估计你已经很不屑了，“切！这么简单的东西还要讲？！”好，我们来讲点复杂的。SRP的原话解释是：
1700454354
1700454355
There should never be more than one reason for a class to change.
1700454356
1700454357
这句话初中生都能看懂，不多说，但是看懂是一码事，实施就是另外一码事了。上面讲的例子很好理解，在实际项目中大家都已经这么做了，那我们再来看看下面这个例子是否好理解。电话这玩意，是现代人都离不了，电话通话的时候有4个过程发生：拨号、通话、回应、挂机，那我们写一个接口，其类图如图1-4所示。
1700454358