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
1700453560
通常的做法是一个实现类实现多个职责，也就是实现多个接口，代码如下：
1700453561
1700453562
//电话
1700453563
1700453564
class Phone implements Connection, Transfer{
1700453565
1700453566
//实现各个接口
1700453567
1700453568
}
1700453569
1700453570
这样的设计才是完美的，一个类实现了两个接口，把两个职责融合在一个类中。你会觉得这个Phone有两个原因引起了变化，是的，但是别忘记了我们是面向接口编程的，我们对外公布的是接口而不是实现类。而且，如果真要实现类的单一职责，就必须使用上面的组合模式，这会引起类间的耦合过重、类的数量增加等问题，人为地增加了设计的复杂性。
1700453571
1700453572
对于单一职责原则，我建议接口一定要做到职责单一，类的设计尽量做到只有一个原因引起变化。
1700453573
1700453574
注意 接口职责一定要单一，实现类职责尽量单一。
1700453575
1700453576
1700453577
1700453578
[
上一页 ]
[ :1.70045353e+09 ]
[
下一页 ]