单一职责原则
如果有一个用户管理类,类图如下
我想,任谁也能看的出这个接口设计的有问题,用户的属性和用户的行为没有分开,应该把用户的信息抽取成一个业务对象,把用户的行为抽取成一个业务对象,按照这个思路对类图进行修正,如下图所示
其实,在实际使用中我们更倾向于使用两个不同的接口: 一个IUserBO,一个IUserBiz
应该有且仅有一个原因引起类的变更
单一职责原则的好处:
- 类的复杂性降低,实现什么职责都有清晰明确的定义
- 可读性提高,复杂性降低了,可读性当然就提高了
- 可维护性提高,可读性提高了,当然更容易维护了
- 变更引起的风险降低.变更是必不可少的,如果接口的单一职责做的好,一个接口修改只对相应的实现类有影响,对其他类无影响,这对系统的扩展性、维护性都有非常大的帮助
单一职责原则适用于接口、类,同样也适用于方法.
单一职责原则是非常优秀的,但是在实际使用中受很多因素的制约
建议,接口一定要做到单一职责,类的设计尽量做到只有一个原因引起变化