读《软件开发沉思录》有感——对象健身操

最近读到一本好书 Thoughtworks Anthology，读后有感。对于其中“对象健身操”这章是由 Jeff Bay 所写。其中以一种我认为是近乎苛刻的规则，来要求人们练习编写一个1000行左右的小项目。

刚开始阅读的时候，我对如此严苛、不近人情的规则戳之以鼻，因为我学习 OO 不是这么学来的。不过，平静下来之后，再看看。从另一个角度来说，对于一个初学者，这样的练习或许是通向 OO 的捷径也未尝不是不可能的。

Jeff Bay 定义的规则如下:

1. 每个方法只使用一级缩进
2. 不要使用 else 关键字
3. 封装所有的原生类型和字符串
4. 一行只使用一个“.”运算符
5. 不要使用缩写
6. 保持实体对象简单清晰
7. 任何类中的实例变量都不要超过两个
8. 使用一级集合
9. 不要使用任何 getters/setters/properties

背后的深意:

每条规则其实是要关注其后的目的，而不是字面的含义。

1. 每个方法只使用一级缩进

这条规则需要关注的关键点是每个方法的长度，也就是常说的一个函数不要超过一屏。而这里把这个限制的更严厉，5行！没错5行以内。

2. 不要使用 else 关键字

这条规则一个方面是限制代码行数，另一个方面是促使开发的时候多使用多态和策略模式来设计类/方法。

3. 封装所有的原生类型和字符串

这条规则其实为以后的重构，功能扩充提供了方便。而其核心思想是 OO 的无处不在，每个对象应该都要含义明确，界定清晰。

4. 一行只使用一个“.”运算符

对这条规则看到标题的时候，我开始认为是不要写很长的调用，仔细阅读后发现其实不然。主要是指过多的“.”在破坏类的封装性。这里关键是要遵守迪米特法则（Law of Demeter）又叫作最少知道原则（Least Knowledge Principle 简写LKP），就是说一个对象应当对其他对象有尽可能少的了解，不要让类的边界跨入到它不应该知道的类型中。

5. 不要使用缩写

不使用缩写原来的函数名会感觉很长，但是其实这条规则是迫使你使用OO思想，去分割类，理顺其中的层次，对象方法的名字只包含一到两个单词，这样不使用缩写也能保持名字比较短。

6. 保持实体对象简单清晰

这条规则更具体的表述是每个类小于50行，每个包小于10个类。类的职责被极度的划分，保证了重用，内聚性。

7. 任何类中的实例变量都不要超过两个

这又是一个极致的规则，太棒了。一下子把类分成两种，一种只维护一个状态，另一种协调两个独立的状态。内聚性，职责的单一性被完美控制住了。

8. 使用一级集合

任何包含集合的类都不能再包含其他的成员变量。这是为了弥补对集合操作的缺失。

9. 不要使用任何 getters/setters/properties

讲述而不要询问（Tell, don't ask）。提供直接访问变量的方法其实也就是变相的破环了数据封装性的原则。

总结

这些规则后面的思想是值得学习的，作为练习是完美的。但是如何在真正的项目中使用是需要考量的，值得去好好思考的！