一、概念
就一个类而言,应该仅有一个引起它变化的原因。
二、详细解释
如果一个类承担的职责过多,就等于把这些职责耦合在一起,一个职责的变化可能会削弱或者抑制这个类完成其它职责的能力。这种耦合会导致脆弱的设计,当变化发生时,设计会遭受到意想不到破坏。软件真正要做的,就是发现职责并把那些职责相互分离。如果你能够想到多于一个的动机去改变一个类,那么这个类就具有多于一个的职责,就应该考虑类的职责分离。编程时,我们要在类的职责分离上多思考,做到单一职责,这样代码才是真正的易维护、易扩展、易复用、灵活多样。
三、举例说明
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模式对代码重构。