重构 — 改善既有的类图设计
条款7:为每个角色增加一个接口
黄国强 2008/6/6
单一职责原则(Single Responsibility Principle,SRP)[1] Robert C. Martin 是这样解释的:Each class should have one and only one reason to change.一个类只能因为一个因素而改变。
从上面所述可以看出,单一职责是针对一个类的。但是我这里有个不同观点,即,单一职责是针对接口的。现实的例子,是我们每个人都承担了太多的职责,这是客观存在的。每个人只承担一个职责,这是理想状态,非常少见。请看图 1 。
现实的例子,比如一个小公司,仅老板一个人,他需要承担从总经理到员工所有的职位的职责。面对不同的客户,他拿出不同职位的名片。随着公司的发展,他会按 职位招聘一些符合这些职位的人。让这些人分担他的职责。在这里。老板就是图1的类4,而总经理职位、部门经理职位、员工职位等就是接口1、2、3。
[1] 敏捷软件开发:原则、模式与实践 英文原名 Agile Software Development: Principles, Patterns, and Practices
作者 : Robert C.Martin
清华大学出版社 | 出版日期 : 2003 年 9 月
条款7:为每个角色增加一个接口
黄国强 2008/6/6
单一职责原则(Single Responsibility Principle,SRP)[1] Robert C. Martin 是这样解释的:Each class should have one and only one reason to change.一个类只能因为一个因素而改变。
从上面所述可以看出,单一职责是针对一个类的。但是我这里有个不同观点,即,单一职责是针对接口的。现实的例子,是我们每个人都承担了太多的职责,这是客观存在的。每个人只承担一个职责,这是理想状态,非常少见。请看图 1 。

图 1
图中类4被类1、2、3调用。承担了为三种不同类型的类服务的职责。根据单一职责原理,重构如图2 。

图 2
图2 中我增加了接口1、2、3,而原先的类4从这三个接口中继承。重构后带来了一个好处,即将类4和类1、2、3解耦。未来,如果需求发生变化,觉得类4过于庞大和复杂,可以将类4重写或分拆。而类1、2、3对此将一无所知。
现实的例子,比如一个小公司,仅老板一个人,他需要承担从总经理到员工所有的职位的职责。面对不同的客户,他拿出不同职位的名片。随着公司的发展,他会按 职位招聘一些符合这些职位的人。让这些人分担他的职责。在这里。老板就是图1的类4,而总经理职位、部门经理职位、员工职位等就是接口1、2、3。
[1] 敏捷软件开发:原则、模式与实践 英文原名 Agile Software Development: Principles, Patterns, and Practices
作者 : Robert C.Martin
清华大学出版社 | 出版日期 : 2003 年 9 月