单一职责原则SRP

一、概念

就一个类而言，应该仅有一个引起它变化的原因。

二、详细解释

如果一个类承担的职责过多，就等于把这些职责耦合在一起，一个职责的变化可能会削弱或者抑制这个类完成其它职责的能力。这种耦合会导致脆弱的设计，当变化发生时，设计会遭受到意想不到破坏。软件真正要做的，就是发现职责并把那些职责相互分离。如果你能够想到多于一个的动机去改变一个类，那么这个类就具有多于一个的职责，就应该考虑类的职责分离。编程时，我们要在类的职责分离上多思考，做到单一职责，这样代码才是真正的易维护、易扩展、易复用、灵活多样。

三、举例说明

1.运用单一职责原则之前的代码

interface Modem
{
    public void dial(string pno);
    public void hangup();

    public void send(char c);
    public void receive();
}

可以看出，Modem接口中包含两个职责，连接管理、数据发送与接收。根据单一职责原则，我们可以将之分为连个功能不同的接口，而非混为一个。

2.运用单一职责原则之后的代码

interface DataChannel
{
    public void send(char c);
      
    public void receive();

}

interface Connection
{
    public void dial(string pno);

    public void receive();

}

如上述代码，数据的发送接收、连接管理等功能都被独立出来，若需要增加或删除其他功能，不会影响到这两个功能发挥作用。

四、使用单一职责原则时应注意

1.一个合理的类，应该仅有一个使它发生变化的原因，即单一职责。

2.在没有变化征兆的情况下，不应使用单一职责或其他的原则。

3.在需求实际发生变化时就应该应用单一职责原则来重构代码。

4.使用测试驱动开发会迫使我们在设计出现臭味之前分离不合理代码。

5.如果测试不能迫使职责分离，僵化性和脆弱性的臭味会变得很强烈，那就应该用Facade或Proxy模式对代码重构。