类的组织
任何的设计最后都将落实到实现上来，漂亮的实现一个类与构造这个类应该是同等重要的。我们在写一个类的实现时，类中的成员应该遵循以下顺序：
1. 公共静态常量
2. 私有静态常量
3. 实体变量
4. 公共函数
此外，我们一般将某个函数的私有工具函数放到这个函数后面，满足自顶向下的原则。这样会使得我们的程序更加的易读，用作者原话说：使读程序像是读文章一样流畅。并且我们在书写类的时候应该尽量保持 变量 和 函数 的私有性。
类应当短小
类同函数一样，应该是短小的。单数类的短小应该与函数的短小区别开来。
通常我们说函数要短小主要还是限制在她的行数上。
而类的短小则是指类的职责应单一。
这里我们涉及到了一个原则： 单一职责原则（SRP）。
SRP认为 ：类或者模块应该只有一条加以修改的理由。
不得不说这是一个很抽象的定义。
我所理解的但一职责原则是要将业务关注的那一部分逻辑的类严格按照功能拆分，这样会让我们的类显得更加灵活，清晰，低复杂性。
SRP 可能会带来的一些影响：
SRP原则无疑会让你拥有更多更小的类，这会让阅读者难以一目了然的抓住全局
花费你更多的时间去设计短小的类
增加代码行数
阅读的时候可能会在多个文档中跳转
不过以上的某些问题可以通过良性组织我们的文档结构加以改善的，对于我而言，让代码拥有更高的可维护性而付出这些代价是值得的。
保持內聚
什么是内聚性？我的理解是类的数据和操作的相关性。通常我们说：
方法操作的变量越多，说明方法和类的黏度越高， 内聚性越强
类中的方法啊和变量相互依赖，形成一个紧密的逻辑整体，则内聚性越高
毫无疑问，当一个类丧失内聚性的时候我们应当拆分它。
为修改而组织
首先，我们的类应该遵循开放-封闭原则（OCP）。即类应当是对扩展开放，对修改关闭的。
其次，类的功能应该是独立的，这样当你要重构一个类的时候，本处的修改不会影响到其他的地方。
如何做到此处的修改不影响其他地方？我们应当隔离修改。这里就说到了另一个原则：依赖倒置原则（DIP）。DIP其本质是类应当依赖于抽象，而不是具体的实现细节。
我对此的理解是 抽象类是依赖与具体的类而产生的，现在我们在构造类的时候应该要去依赖别的抽象类，所以叫做依赖倒置。
遵循依赖倒置原则可以有效的降低耦合，隔离细节。
