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
1700454359
1700454360
1700454361
1700454362
图1-4 电话类图
1700454363
1700454364
我不是有意要冒犯IPhone的，同名纯属巧合，我们来看一个这个过程的代码，如代码清单1-2所示。
1700454365
1700454366
代码清单1-2 电话过程
1700454367
1700454368
public interface IPhone{
1700454369
1700454370
//拨通电话