类的组织 Class Organization
公共函数调用的私有函数，紧跟公共函数后，这符合自上向下原则，让程序读起来像一篇报纸文章
封装 Encapsulation
有时为了测试，会把 private 的变量或函数变成 protected 或 Internal 的
首先想办法隐藏，保有隐私，发送封装总是下策
类应该短小 Classes Should Be Small!
对于函数，我们通过计算代码行衡量其大小
对于类，我们采用不同的衡量方法，即计算其 权责 responsibility
类的名称应当描述其权责，类名越含糊，该类越有可能拥有过多权责
- 如类名中包含含义模糊的词，如 processor manager 或 super，那就意味着有不恰当的权责聚集情况存在
单一权责原则 The Single Responsibility Principle
SRP 认为，类或模块应该有且只有一条加以修改的理由，该原则给出了权责的定义，同时这也是关于类的长度的指导方针，类应该只有一个权责 - 只有一条修改的理由
让软件能工作 和 让软件保持整洁，是两种截然不同的工作
在程序能工作后，不应立即转向下个问题，应该回头将臃肿的类切分为只有单一权责的去耦式单元
数量巨大的短小单一目的类也许会导致难以一目了然的抓住全局，但是少量巨大的，拥有多目的的类，会让你去了解一大堆目前并不需要的东西，这会让事情变得更复杂
总之，系统应该由 许多短小的类 而不是 少量巨大的类 组成，每个小类封装一个权责，只有一个修改的原因，并与少数其他类一起协同达成期望的系统行为
内聚 Cohesion
类应该只有少数实体变量，且类中的每个方法都应该操作一个或多个这种变量，通常方法操作的变量越多，就越黏聚到这个类上，如果类中的每个变量都被每个方法所使用，就说该类具有最大的内聚性
保持函数和参数列表短小的策略，有时会导致 一组子集方法所用的实体变量数量增加，此时意味着至少有一个类要从大类中挣扎出来，应当尝试将这些变量和方法分拆到两个或多个类中，让新的类更为内聚
保持内聚性就会得到许多短小的类 Maintaining Cohesion Results in Many Small Classes
将大函数拆分为许多小函数时，这些小函数往往共享一些实体变量，此时，可以把这些共享某些实体变量的函数和实体变量拆分到新的小类中，这样程序会更加有组织，会拥有更为透明的结构
为了修改而组织 Organizing for Change
对于多数系统，修改将一直持续。在整洁的系统中，我们对类加以组织，以降低修改的风险
- 在理想系统中，通过扩展系统而非修改现有代码来添加新特性
隔离修改 Isolating from Change
在 OO 世界里，具体类包含实现细节，而抽象类只是呈现概念。依赖具体细节的客户类，一旦细节改变，就会有风险。— 通过借助 接口 和 抽象类 来隔离这些细节带来的影响
依赖倒置原则 Dependency Inversion Principle (DIP)
DIP 认为类应当依赖抽象，而不是依赖具体细节
依赖抽象概念，这种抽象概念帮我们隔离了 特定的细节