代码整洁之道精华——第十章 类

阅读本文有两种原因：第一，你是个程序员；第二，你想成为更好的程序员。你如果想成为更好的程序员，那就请细细品味文章内容，它绝不会让你失望。
代码整洁之道教给大家如何编写整洁的代码，而不仅仅是能运行的代码，这对于编程者而言很重要。我在读这本书的第一遍时没什么感觉，但在读第二遍时觉得它确实挺不错的，如果有机会的话我会读第三遍。下面是我在读书过程中摘录的精华内容，希望大家认真对待。各位看官如果读完本文觉得书中的精华内容挺合自己的胃口，那就可以抽出时间认真地读一下这本书。

1、遵循标准的Java约定，类应该从一组变量列表开始。如果有公共静态变量，应该先出现。然后是私有静态变量，以及私有实体变量。很少会有公共变量。
公共函数应跟在变量列表之后。我们喜欢把由某个公共函数调用的私有工具函数紧随在该公共函数后面，这符合了自顶向下原则，让程序读起来就像一篇报纸文章。
2、类的名称应该描述其权责。实际上，命名正是帮助判断类的长度的第一个手段。如果无法为某个类命以精确的名称，这个类大概就太长了。类名越含糊，该类越有可能拥有过多权责。
3、有大量短小类的系统并不比有少量庞大类的系统拥有更多移动部件，其数量大致相等。问题是：你是想把工具归置到有许多抽屉、每个抽屉中装有定义和标记良好的组件的工具箱中呢？还是想要几个能随便把所有东西扔进去的抽屉？
每个达到一定规模的系统都会包括大量逻辑和复杂性。管理这种复杂性的首要目标就是加以组织，以便开发者知道在哪能找到所需的东西，并且在某个特定时间只需要理解直接有关的复杂性。反之，拥有巨大、多目的类的系统，总是让我们在目前并不需要了解的一大堆东西中艰难跋涉。
再强调一下：系统应该由许多短小的类而不是少量巨大的类组成。每个小类封装一个权责，只有一个修改的原因，并与少量其他类一起协同达到期望的系统行为。
4、类应该只有少量实体变量，类中的每个方法都应该操作一个或多个这种变量。通常而言，方法操作的变量越多，就越粘聚到类上。如果一个类中的每个变量都被每个方法所使用，则该类具有最大的内聚性。
一般来说，创建这种极大化的内聚类既不可取也不可能；另一方面，我们希望内聚性保持在较高的位置。内聚性高，意味着类中的方法和变量互相依赖、互相结合成一个逻辑整体。
5、需求会改变，所以代码也会改变。在面向对象概念中我们学习到，具体类包含实现细节（代码），而抽象类则只呈现概念。依赖于具体细节的客户端，当细节改变时，就会有风险。我们可以借助接口和抽象类来隔离这些细节带来的影响。
6、如果系统解耦到足以简单测试的程度，也就更灵活，更加可复用。部件之间的解耦代表着系统中的元素互相隔离得很好。隔离也让系统对每个元素的理解变得更加容易。
通过降低连接度，我们的类就遵循了另一条设计原则，依赖倒置原则（Dependency Inversion Principle，DIP）。本质而言，DIP认为类应该依赖于抽象而不是依赖于具体细节。

抛开所有细节不谈，代码整洁之道总体来说可以分为7点：

• 运行所有测试
• 减少重复代码
• 提高表达力
• 提早构建简单抽象
• 类和方法都只做好一件事
• 尽量减少类和方法的数量
• 努力，让营地比你来时更干净。努力，让世界比你来时更干净。努力，让代码比你签出时更干净。