java设计模式（一）单一职责原则single responsibility principle（SRP）

单一职责定义

应该有且仅有一个原因引起类的变更。

单一原则代码实现（原始版）

比如说：现在需要实现电话通话的4个过程：拨号，通话，回应，挂机。
此时设计一个接口：

public interface IPhone{
//拨通电话
void dial(String phoneNumber);
//通话
void chat（Object o）；
//挂机
void hangup();

}

看到上面的代码，设计几乎完美，但是却是违背了单一职责要求：一个接口或者类只有一个原因引起变化，也就是一个接口或者类只有一个职责，他就是负责意见事情。再看看上面的接口只负责一件事情吗？是只有一个原因引起变化吗？
IPhone这个接口可不只是只有一个职责，它包含了两个职责：一个是协议管理，一个是数据传送。dial(）和hangup()实现的是协议管理，分别负责拨号接通和挂机；chat()实现的是数据的数据的传送，把我们的话转换成模拟信号或者数字信号传递到对方，然后再把对方传递过来的信号还原成我们听得懂的语言。

代码实现二（升华版）

我们通过组合的形式：定义两个接口组合（强的耦合关系，你和我都有共同的生命周期）

public inteface IConectionManage{
void dial(String phoneNumber);
void hangup();
}
public inteface IDataTansfe{
dataTransfer(IConectionManage cm);
}

public Phone implements IDataTansfe,IConectionManage{
}

这样的设计才是完美的，一个类实现两个接口，把两个职责融合在一个类中。你可能会觉得这个Phone类有两个原因引起了变化啊。是的，但是别忘记了，我们java是面向接口编程，我们对外公布的是接口，而不是实现类。

总结

单一职责原则有什么好处：
1.类的复杂性降低，实现什么职责都有清晰明确的定义；
2.可读性提高，复杂性降低，那当然可读性提高了；
3.可维护性提高，可读性提高，当然更容易维护了；
4.变更引起的风险降低，变更时必不可少的，如果接口的单一职责做得好，一个接口修改只对相应的实现类有影响，对其他的接口无影响，这对系统的扩张性、维护性都有非常大的帮助。