设计模式之单一职责原则

单一职责原则(SRP (Single Responsibility Principle))

单一职责原则定义：

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

很简单的一个类图，很容易可以看出问题所在，用户的属性和行为没有分开；
应该用户的信息抽取成一个业务对象接口，行为抽取成一个业务逻辑接口

修改后：

• 重新拆封成两个接口，IUserBO负责用户的属性，简单地说，IUserBO的职责就是收集和反馈用户的属性信息；
• IUserBiz负责用户的行为，完成用户信息的维护和变更。

回到单一职责的定义：应该有且只有一个原因引起类的变更，这里就是把一个接口分成两个接口，依赖了单一职责原则。

单一职责的思考

但是问题来了，一个职责一个接口，但问题是“职责”没有一个量化的标准，一个类到底要负责那些职责？这些职责该怎么细化？细化后是否都要有一个接口或类？

单一职责原则提出了一个编写程序的标准，用“职责”或“变化原因”来衡量接口或类设计得是否优良，但是“职责”和“变化原因”都是不可度量的，因项目而异，因环境而异。

单一职责的优点

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