代码整洁之道
摘要:代码整洁之道 1.代码质量与其整洁度成正比 2.乐嚼是在丹麦最受欢迎的糖果品种之一,它浓郁的甘草味道,完美地弥补了此地潮湿且时常寒冷的天气 4.宏大建筑中最细小的部分,比如关不紧门,有点儿没铺平的地板,甚至凌乱的桌面,都会将整个大局的魅力毁灭殆尽 5.架构只是软件开发用到的借喻之一,主要用在那种等同
阅读全文
posted @
2018-04-02 15:11
Sharpest
编辑
被拒绝的遗赠 (Refused Bequest)
摘要:子类应该继承超类的函数和数据。但如果它们不想或不需要继承,又该这么办呢?它们得到所有礼物,却只从中挑选几样来玩。 按传统说法,这就意味着继承体系设计错误。你需要为这个子类新建一个兄弟类,再次运用 push down Method (函数下移)和 push down field (字段下移)把所有用不
阅读全文
posted @
2018-02-09 10:53
Sharpest
编辑
过多的注释 (Comments)
摘要:我们之所以在这里提到注释,是因为人们常把它当做除臭剂来使用。常常会有这样的情况:你看到一段代码有着长长的注释,然后发现,这些注释之所以存在是因为代码很糟糕。 注释可以带我们找到代码中的坏味道。找到坏味道后,我们首先应该以各种重构手法把坏味道去除。完成之后我们常常会发现:注释已经变得多余了,因为代码已
阅读全文
posted @
2018-02-09 10:51
Sharpest
编辑
不完美的类库----Introduce Foreign Method(引入外加函数)
摘要:你所使用的server class需要一个额外函数,但你无法修改这个class。 在client class中建立一个函数,并以一个server class实体作为第一引数(argument)。 Date newStart = new Date(previousEnd.getYear(), prev
阅读全文
posted @
2018-02-09 10:47
Sharpest
编辑
不完美的库类----Introduce Local Extension(引入本地扩展)
摘要:你所使用的server class需要一些额外函数,但你无法修改这个class。 建立一个新class,使它包含这些额外函数。让这个扩展品成为source class的subclass(子类)或wrapper(外覆类)。 Client Class... private nextDate(Date):
阅读全文
posted @
2018-02-09 10:43
Sharpest
编辑
不完美的库类 (Incomplete Library Class)
摘要:复用常被视为对象的终极目的。不过复用的意义常被高估:大多数对象只要够用就好。但是无可否认,许多编程技术都建立在程序库的基础上。 库类的构筑者没用未卜先知的能力,不能因此责怪他们。麻烦的是库往往构造的不够好,而且往往不可能让我们修改其中的类使它们完成我们希望完成的工作。这是否意味着那些经过实践检验的技
阅读全文
posted @
2018-02-09 10:42
Sharpest
编辑
java.util.Collections.unmodifiableSet()方法实例
摘要:unmodifiableSet() 方法返回指定set的不可修改视图。 声明 以下是java.util.Collections.unmodifiableSet()方法的声明。 参数 s--这是一个不可修改视图是要返回的集合。 s--这是一个不可修改视图是要返回的集合。 返回值 在方法调用返回指定se
阅读全文
posted @
2018-02-09 10:35
Sharpest
编辑
纯数据类---Encapsulate Collection(封装群集)
摘要:有个函数(method)返回一个群集(collection).让这个函数返回该群集的一个只读映件(read-only view), 并在这个class中提供[添加/移除](add/remove)群集元素的函数. Person... getCourse() :Set setCourse(Set) ==
阅读全文
posted @
2018-02-09 10:33
Sharpest
编辑
纯数据类---Self Encapsulate Field(自封装值域)
摘要:你直接访问一个值域(field),但与值域之间的耦合关系逐渐变得笨拙。 为这个值域建立取值/设值函数(getting and setting methods ),并且只以这些函数来访问值域。 private int _low, _high; boolean includes (int arg) {
阅读全文
posted @
2018-02-08 19:11
Sharpest
编辑
中间人--Remove Middle man
摘要:5Hide Delegate(隐藏“委托关系”) 概要 客户通过一个委托关系来调用另一个对象。 在服务类上建立客户所需的所有函数,用以隐藏委托关系。 动机 如果某个客户先通过服务对象的字段或者属性得到另一个对象,然后调用后者的函数,那么客户就必须知晓这一层委托关系。万一委托关系发生变化,客户也得相应
阅读全文
posted @
2018-02-08 18:48
Sharpest
编辑
中间人---Inline Method (内联函数)
摘要:一个函数调用的本体与名称同样清楚易懂。在函数调用点插入函数体,然后移除该函数。 int GetRating() { return MoreThanfiveLateDeliverise() ? 2 : 1; } bool MoreThanfiveLateDeliverise() { return _n
阅读全文
posted @
2018-02-08 18:42
Sharpest
编辑
狎昵关系-- replace inheritance with delegation(以委托取代继承)
摘要:某个子类只使用超类接口中的一部分,或是根本不需要继承而来的数据。 在子类中新建一个字段用以保存超类;调整子类函数,令它改而委托超类;然后去掉两者之间的继承体系。 动机: 一开始继承了一个类,随后发现超类中的许多操作并不真正适用于子类。这种情况下,你所拥有的接口并未真正反映出子类的功能。你可能发现你从
阅读全文
posted @
2018-02-08 17:30
Sharpest
编辑
狎昵关系--change bidirectional association to unidirectional (将双向关联改为单向关联)
摘要:两个类之间有双向关联,但其中一个类如今不再需要另一个类的特性。 动机: 双向关联很有用,但你必须为它付出代价,那就是维护双向连接。 大量的双向连接也很容易造成“僵尸对象”。 双向关联也迫使两个类之间有了依赖:对其中一个类的任何修改,都可能引发另一个类的变化。 做法: 找出保存“你想去除的指针”的字段
阅读全文
posted @
2018-02-08 17:28
Sharpest
编辑
狎昵关系 (Inappropriate Intimacy)
摘要:有时候你会看到2个类过于亲密,花费太多时间起探究彼此的private成分。你可以采用Move Method (搬移函数)和 Move Field (搬移字段)帮他们划清界限。你也可以看看是否可以运用 Change Bidirectional Association to Unidirectional
阅读全文
posted @
2018-02-08 16:48
Sharpest
编辑
异曲同工的类 (Alternative Classes with Different Interfaces)
摘要:如果2个函数做同一件事,却有着不同的签名,请运用 Rename Method (函数改名)根据它们的用途重新命名。但这往往不够,请反复运用 Move Method (搬移函数)将某些行为移入类,直到2者的协议一致为止。如果你必须反复而赘余的移入代码才能完成这些,或许可运用Extract Superc
阅读全文
posted @
2018-02-08 16:41
Sharpest
编辑
令人迷惑的临时字段(Temporary Field)
摘要:有时你会看到这样的对象:其内某个实例变量仅为某种特定情况而设。这样的代码让人不易理解,因为你通常认为对象在所有时候都需要它的所有变量。在变量未被使用的情况下猜测当初设置目的,会让你发疯。 请使用Extract Class (提炼类)给这些变量创造一个家,然后把所有和这些变量相关的代码都放进这个新家,
阅读全文
posted @
2018-02-08 15:36
Sharpest
编辑
过度耦合的消息链条--Hide Delegate(隐藏委托关系)
摘要:客户直接调用其server object(服务对象)的delegate class。 在server端(某个class)建立客户所需的所有函数,用以隐藏委托关系(delegation)。 Client--〉Person | | Department ==〉 Client --〉Person--〉De
阅读全文
posted @
2018-02-08 15:08
Sharpest
编辑
message chains (过度耦合的消息链)
摘要:一个对象请求另一个,后者在请求下一个对象,....这就是消息链。采取这种方式,意味客户代码将与查找过程中的导航结构紧密耦合,一旦对象间的关系发生任何变化,客户端就不得不做出相应修改。 这时候应该使用hide delegate。 通常更好的手法:先观察消息链最终得到的对象是用来干什么的,看看能否以ex
阅读全文
posted @
2018-02-08 15:07
Sharpest
编辑
夸夸其谈未来性(Speculative Generality)
摘要:如果你的某个抽象类其实没有太大作用,请运用 Collapse Hierarch (折叠继承体系)。不必要的委托可运用 Inline Class (将类内联化)除掉。如果函数的某些参数未被用上,可对它实施 Remove Parameter (移除参数)。如果函数名称带有多余的抽象意味,应该对它实施Re
阅读全文
posted @
2018-02-08 14:52
Sharpest
编辑
平行集成体系---Move Field
摘要:Motivation 如果某个field,在其所驻class之外的另一个class中有更多的函数使用了它,那么可以考虑将这个field移动到另一个class。 Mechanics 1 如果field属性为public,应该先使用EncapsulateField或者Self Encapsulate F
阅读全文
posted @
2018-02-08 14:39
Sharpest
编辑