对象健身操----Thought Works文集

       最近看到了一本非常值得阅读的书《软件开发沉思录--Thought Works 文集》， 13 篇美文荟萃软件开发精华，来自软件界思想领袖们的经验心得，为你开启敏捷开发之门。其中有一篇文章非 常经典，让我爱不释手。现在我把里面的部分思想摘录于此，以此来警戒自己。

九步迈向优秀软件设计：

面向对象编程一直在鼓励我们摆脱过程式代码的桎梏，帮助我们以累加的方式编写代码，并重用已有的组件。优秀设计背后的核心概念其实并不高深：内聚性、松耦、零重复、封装、可测试性、可读性以及单一职责。作者给出了一系列实践规则，让我们将良好的面向对象设计原则变得更加具体。

规则1 ：方法只使用一级缩进

庞大的方法通常缺少内聚性。一个常见的原则是将方法的行数控制在5 行之类。每个方法都只关注一件事，而它们所在的泪也只做一件事。

规则2 ：拒绝 else 关键字

层层嵌套的条件判断，连绵数页的case 语句。对于简单的条件判断，我们可以使用“卫语句”和“提前返回”替换它。

规则3 ：封装所有的原生类型和字符串

规则4 ：一行代码只有一个“ . ”运算符

一行包含了多个“. ”的代码，很难判断出一个行为的职责应该由哪个对象来承担。迪米特法则：只和身边的朋友交流。

规则5 ：不要使用缩写

   我们总会在不自觉地在类名，方法名或者变量名中使用缩写。缩写会令人迷惑，也容易隐藏一些严重的问题。尽量保持类名和方法名称中只包含一到两个单词。

规则6 ：保持实体对象简单清晰

   每个类的长度都不能超过50 行，每个包所包含的文件不超过 10 个。随着类变得越来越小，职责越来越少，加之包的大小也受限制，因此包中的泪越来越集中，它们能协调完成一个共同的目标。包和类一样，也应该是内聚的。

规则7 ：如何类中的实例变量都不要超过两个

   大多数的类应该只负责处理单一的状态变量，有时也可以拥有两个状态变量。每当为类添加一个实例变量，就会立即降低类的内聚性。

规则8 ：使用一流的集合

规则9 ：不使用任何 Getter/Setter/Property

   这条规则通常被描述为：“讲述而不要询问（Tell, don't ask ）”。

总结：能够帮助程序员获得面向对象程序设计的圣杯------- 数据封装。不要使用 else, 尽量简化条件判断逻辑，鼓励程序员适当使用多态。命名策略，鼓励程序员使用一致的，直接的命名标准，不要使用难以理解的缩写。

总之：就是想尽办法消除代码中的重复。我们每天都要面对复杂的问题，而我们的目标是：用简练的代码表达出简单而优美的抽象。

个人感觉：这些规则太不可思议了，完全打破了我们平时的思维编程习惯吗。给我的第一反应就是：我们能完全按照这些规则来做吗？在日常的软件开发中可行吗？能够完整遵守这些规则吗？可是作者最后说了这么一句：我们刚刚完成了一个超过100 000 行代码的系统，它严格遵守本文中提到的所有规则。参与这个项目的程序员全部都认真地遵守了上述规则。最终每个人都非常高兴地看到：如果努力地拥抱简单，那么开发过程会快乐得多。

拥抱简单，快乐编程，享受编程。