1700453510
职责单一,会让类中的代码量减少,我们可以一眼看穿该类的实现方式,有助于提供代码的可读性,这也间接提升了代码的可维护性。
1700453511
1700453512
(3)降低变更风险
1700453513
1700453514
变更是必不可少的,如果接口(或类)的单一职责做得好,一个接口修改只对相应的实现类有影响,对其他的接口无影响,那就会对系统的扩展性、维护性都有非常大的帮助。
1700453515
1700453516
既然单一职责有这么多的优点,那我们该如何应用到设计和编码中呢?下面以电话通信为例子来说明如何实施单一职责原则:
1700453517
1700453518
(1)分析职责
1700453519
1700453520
一次电话通信包含四个过程:拨号、通话、回应、挂机,我们来思考一下该如何划分职责,这四个过程包含了两个职责:一个是拨号和挂机表示的是通信协议的链接和关闭,另外一个是通话和回应所表示的数据交互。
1700453521
1700453522
问题是我们依靠什么来划分职责呢?依靠变化因素,我们可以这样考虑该问题:
1700453523
1700453524
通信协议的变化会引起数据交换的变化吗?会的!你能在3G网络视频聊天,但你很难在2G网络上实现。
1700453525
1700453526
数据交互的变化会引起通信协议的变化吗?会的!传输2KB的文件和20GB的文件需要的不可能是同一种网络,用56KB的“小猫”传输一个20GB的高清影视那是不可行的。
1700453527
1700453528
(2)设计接口
1700453529
1700453530
职责分析确定了两个职责,首先不要考虑实现类是如何设计的,我们首先应该通过两个接口来实现这两个职责。接口的定义如下。
1700453531
1700453532
//通信协议
1700453533
1700453534
interface Connection{
1700453535
1700453536
//拨通电话
1700453537
1700453538
public void dial();
1700453539
1700453540
//通话完毕,挂电话
1700453541
1700453542
public void hangup();
1700453543
1700453544
}
1700453545
1700453546
//数据传输
1700453547
1700453548
interface Transfer{
1700453549
1700453550
//通话
1700453551
1700453552
public void chat();
1700453553
1700453554
}
1700453555
1700453556
(3)合并实现
1700453557
1700453558
接口定义了两个职责,难道实现类就一定要分别实现这两个接口吗?这样做确实完全满足了单一职责原则的要求:每个接口和类职责分明,结构清晰,但是我相信读者在设计的时候肯定不会采用这种方式,因为一个电话类要把ConnectionManager和DataTransfer的实现类组合起来才能使用。组合是一种强耦合关系,你和我都有共同的生命期,这样的强耦合关系还不如使用接口实现的方式呢!而且这还增加了类的复杂性,多出了两个类。
1700453559
[
上一页 ]
[ :1.70045351e+09 ]
[
下一页 ]