代码整洁之道的前几章都是在讨论如何编写良好的代码行和代码块。
这一章开始探讨代码组织的更高层面：类。
一、类的组织
遵循Java的约定，类应该从一组变量列表开始，接着是函数，大致顺序如下：
1.公有静态常量
2.私有静态变量
3.公有普通变量
4.私有普通变量
5.公共函数
6.私有函数
把某个公共函数调用的私有工具函数放在紧随该公共函数后的位置，这样符合自顶向下规则。
封装：保持变量和工具函数的私有性，但是也并不是墨守成规。有时，我们也需要用到protected类型的变量或工具函数，好让测试代码访问到。
二、类应该精简
跟函数一样，类的首要规则是要更精短。
对于函数我们可以通过行数来衡量大小。对于类，我们通过权责（responsibility）来衡量。
类的名称应该描述其权责。
实际上，命名正是帮助判断类的长度的第一个手段。如果无法为某个类命以精确的名称，这个类大概就太长了。类名越含混，该类可能拥有了过多的职责。
2.1 单一职责原则
单一职责原则定义是：不要存在多于一个导致类变更的原因。通俗地说，即一个类只负责一项职责，类或模块应有且只有一条加以修改的理由。
系统应该由许多短小的类而不是少量巨大的类组成。每个小类封装一个职责，只有一个修改的原因，并与少数其他类一起协同达成期望的系统行为。
关于单一职责原则，感兴趣的读者可自行搜索相关介绍。例如：http://c.biancheng.net/view/1327.html
2.2 内聚
经常听到高内聚低耦合，内聚其实就是指，类应该只有少量成员变量，类中的每个方法都应该操作一个或多个成员变量。通常而言，方法操作的变量越多，就越黏聚到类上。如果一个类中的每个变量都被每个方法使用，则该类具有最大的内聚性。
一般来说，创建这种最大内聚性的类既不可取也不可能，另一方面，我们希望类能有高内聚性，意味着类中的方法和变量相互依赖、互相结合成一个逻辑整体。
如下面这个Stack类所示，这是一个非常内聚的类，三个方法中，只有size()方法没能用到所有成员变量。
public class Stack {
private int topOfStack = 0;
List<Integer> elements = new LinkedList<Integer>();
public int size() {
return topOfStack;
}
public void push(int element) {
topOfStack++;
elements.add(element);
}
public int pop() throws PoppedWhenEmpty {
if (topOfStack == 0)
throw new PoppedWhenEmpty();
int element = elements.get(--topOfStack);
elements.remove(topOfStack);
return element;
}
}
另外之前函数一章提到过，函数应该尽量短、参数列表尽量短。这有可能会导致类中出现很多只在个别方法中用到的属性，出现这种情况时，应该考虑把这些成员变量和方法分拆到两个或多个类中，让新的类更内聚。
三、为了修改而组织
需求会改变，所以代码也会被修改，所以为了更方便的修改要在设计类的时候进行精心的组织。
在面向对象入门知识中我们学习到，具体类包含实现细节（代码），而抽象类则呈现概念。依赖于具体细节的客户类，当细节改变时，就会有风险。我们可以借助接口和抽象类来隔离这些细节带来的影响。
其实这就是依赖倒置原则（Dependency Inversion Principle , DIP），因为依赖倒置原则的本质，实际上就是认为类应该依赖于抽象，而不是依赖于具体细节。
尽量对设计解耦，做好系统中的元素的相互隔离，做到更加灵活与可复用。
还要考虑面向对象设计的另一个关键原则：OCP（开放-闭合原则），类应该对扩展开放，对修改封闭。在理想系统中，我们通过扩展系统而非修改现有代码来添加新特性。
参考
《代码整洁之道》
