单一职责原则:就一个类而言,应该仅有一个引起它变化的原因。
什么是职责?在SRP中,我们把职责定义为“变化的原因”。如果你能够想到多于一个的动机去改变一个类,那么这个类就具有多于一个的职责。
每个职责都是变化的一个轴线。当需求变化的时候,这种变化会反映为类的职责的变化。如果一个类承担的职责过多,就等于把这些职责耦合在一起,而一个职责的变化可能会削弱甚至是抑制这个类完成其他职责的能力。当变化发生时,引起意想不到的破坏。
SRP是所有原则中最简单的一个,也是最难正确运用的一个。因为我们会很自然地把职责结合在一起。
软件设计有很多真正要做的事情就是发现职责并把它们相互分离。
考虑下面这种情况:
interface drawable {
public void setResouces(Byte[] bytes);
public void setStatus();
public void show();
public void drawOnScreen(Canvas canvas);
}
上述"图片"接口提供了两类接口,一类是设置图片样式和内容的显示接口类,一类是用于显示图片的接口类。
很明显,上述接口显示出了两个职责。
现在的问题是,我们应该把这两个职责区分开吗?
这取决于应用程序变化的方式。
如果应用程序的变化总是会同时影响到这两个职责,则我们不必分离它们。而且分离它们后,会带来不必要的复杂性。
如果应用程序的变化会影响到单个接口类,则这两个职责应该被分离。不分离的话,这个设计会具有僵化性。