前言
决定把责任放在哪对于对象设计是最重要的之一。重构可以很好的解决这个问题。以下是笔者的重构方法
注:客户:调用接口
客户类:使用了接口的类
服务类:提供服务的类
Move Method(搬移函数)。
问题
你的程序中,有个函数与其所驻类之外的另一个类进行更多交流:调用后者或者被后者调用。
方法
在该函数最常引用的类中建立一个有着类似行为的新函数,将旧函数编程一个单纯的委托函数,或是将旧函数完全移除。
动机
一个类有太多行为,或者与另一个类有太多合作形成高度耦合,为了让系统中的类更简单,干净利落地实现系统交付的任务。
Move Field(搬移字段)。
问题
在你的程序中,某个字段被其所驻类之外的另一个类更多地用到。
方法
在目标类新建一个字段,修改源字段的所有用户,令它们改用新字段。
动机
对于一个字段,在其所驻类之外的另一个类中有更多的函数使用了它。
Extract Class(提炼类)。
问题
某个类做了应该由两个类做的事情。
方法
建立一个新类,将相关的字段和函数从旧类搬移到新类。
动机
一个类应该是一个清楚的抽象,处理一些明确的责任,实际工作中,类可能不断扩大,加入很多新功能,这样的类往往有大量函数和数据,这样的类往往不易理解,所以需要提炼类,将其中独立的功能提炼出来形成新的类。
Inline Class(将类内联化)。
问题
某个类没有做太多事情。
方法
将这个类的所有特性搬移到另一个类中,然后移除原类。
动机
正好与Extra Class相反,如果一个类不再承担足够责任,不再有单独存在的理由,就需要将这个类塞进另一个类中。
Hide Delegate(隐藏“委托关系”)。
问题
客户通过一个委托类来调用另一个对象。比如person类(人)调用department类(部门)来获取manager类(经理)
方法
在服务类(人)上建立客户所需的所有函数,用以隐藏委托关系。
动机
将委托关系隐藏起来,防止委托关系发生变化,客户也得相应变化,从而去除这种依赖。
Remove Middle Man(移除中间人)。
问题
某个类做了过多的简单委托动作。
方法
让客户直接调用受托类。
动机
在Hide Delegate中,封装受托对象是有好处的,但是也是有代价的:每当客户要使用受托类新特性,就必须在服务端添加一个简单委托函数,随着受托类功能增多,这个过程会让人痛苦,服务类变成了一个“中间人”,此时应该移除中间人,让客户直接调用受托类。
Introduce Foreign Method(引入外加函数)。
问题
你需要为提供服务的类增加一个函数,但你无法修改这个类。
方法
在客户类中建立一个函数,并以第一参数形式传入一个服务类实例。
动机
使用一个类的时候需要一个新的服务,但是不能修改源码,就得在客户端编码,补足函数所需功能。但是如果为一个服务类建立了大量外加函数,就不该使用这个重构了,应该用Introduce Local Extension。
Introduce Local Extension(引入本地扩展)。
问题
你需要为服务类提供一些额外函数,但你无法修改这个类。
方法
建立一个新类,使它包含这些额外的函数。让这个扩展品成为源类的子类或包装类。
动机
类的作者也无法预见未来,因此常常没能为后来者准备足够有用的函数。如果无法修改源码,需要两个以上外加函数,就需要将这些函数组织在一起,放到一个恰当的地方。
总结
1:“决定把责任放在哪儿” 试用 方法: Move Method , Move Filed ,如果需要都试用先试用 Move field 再使用 Move Method 。
2:类责任过多 --->Extract class 方法
3:类责任太少---> inline class
4:一个类使用另一个类 ---> Hide Delegate
5:隐藏委托类导致拥有者的接口经常变化---> Romove Middle Man
6:不能访问类的源码但是想将责任移到不可修改的类中 ---> Introduce Foreign Methon(少量函数) & Introduce Local Extension(较多函数)
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。