单一职责原则

如果有一个用户管理类,类图如下

我想,任谁也能看的出这个接口设计的有问题,用户的属性和用户的行为没有分开,应该把用户的信息抽取成一个业务对象,把用户的行为抽取成一个业务对象,按照这个思路对类图进行修正,如下图所示

其实,在实际使用中我们更倾向于使用两个不同的接口: 一个IUserBO,一个IUserBiz

单一职责原则定义

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

单一职责原则的好处:

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

单一职责原则适用于接口、类,同样也适用于方法.

单一职责原则是非常优秀的,但是在实际使用中受很多因素的制约

建议,接口一定要做到单一职责,类的设计尽量做到只有一个原因引起变化

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!