敏捷软件开发

单一职责原则(SRP)

介绍

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

实现方法之一就是把不同职责分离到不同的类中。因为每一个职责都是变化的一个轴线。当需求变化时,该变化会反映为类的职责的变化。如果一个类承担了多于一个的职责,那么引起它变化的原因就会有多个。

如果一个类承担的职责过多,就等于把这些职责耦合在了一起。一个职责的变化可能会削弱或者抑制这个类完成其他职责的能力。这种耦合会导致脆弱的设计,当变化发生时,设计会遭受到意想不到的破坏。

职责

关于职责,可以定位为“变化的原因”。如果你能够想到多于一个的动机去改变一个类,那么这个类就具有多于一个的职责。但我们习惯以组的形式去考虑职责。例如下面的Modem接口,大多数人会认为这个接口看起来非常合理:

interface Modem
{
    public void dial(String pno);
	public void hangup();
	public void send(char c);
	public void recv();
}

然而,该接口中却显示了两个职责。第一个职责是连接管理;第二个职责是数据通信。dial和hangup函数进行调制解调器的连接处理,而send和recv函数进行数据通信。

这两个职责应该被分开吗?这依赖于应用程序变化的方式。如果应用程序的变化会影响连接函数的签名,那么这个设计就具有僵化性的臭味,因为调用send和recv的类必须要重新编译,部署的次数常常会超过我们希望的次数。这种情况下,这两个职责应该被分离,这样做避免了客户应用程序和这两职责耦合在一起。

另一方面,如果应用程序的变化方式总是导致这两个职责同时变化,那么就不必分离它们。实际上,分离它们就会具有不必要的复杂性的臭味。

在此还有一个推论。变化的轴线仅当变化实际发生时才具有真正的意义。如果没有征兆,那么去应用SRP,或者任何其他原则都是不明智的。

开放——封闭原则(OCP)

posted @ 2017-04-27 10:21  sheshiji  阅读(119)  评论(0编辑  收藏  举报