1、类应该从一组变量列表开始。如果有公共静态常量，应该先出现。然后是私有静态变量，以及私有实体变量。很少会有公共变量。公共函数应跟在变量列表之后。而公共函数调用的私有工具函数紧随在该公共函数后面。这符合了自顶向下原则，让程序读起来就像一篇报纸文章。
2、想办法使之保有隐私。放松封装总是下策。
3、类应该短小，这个短小用类的权责来衡量。类的名称应当描述其权责。实际上，命名正是帮助判断类的长度的第一个手段。如果无法为某个类命以精确的名称，这个类大概就太长了。类名越含混，该类越有可能拥有过多权责。
4、单一权责原则。单一权责原则（SRP）认为，类或模块应有且只有一条加以修改的理由。
5、系统应该由许多短小的类而不是少量巨大的类组成。每个小类封装一个权责，只有一个修改的原因，并与少数其他类一起协同达成期望的系统行为。
6、类应该只有少量实体变量。类中的每个方法都应该操作一个或多个这种变量。保持函数和参数列表短小的策略，有时会导致为一组子集方法所用的实体变量数量增加。出现这种情况时，往往意味着至少有一个类要从大类中挣扎出来。你应当尝试将这些变量和方法分拆到两个或多个类中，让新的类更为内聚。
7、将大函数拆为许多小函数，往往也是将类拆分为多个小类的时机。因为这往往会多出许多实体变量，降低了类的内聚性。
8、开放-闭合原则（OCP）：类应当对扩展开放，对修改封闭。
9、在理想系统中，我们通过扩展系统而非修改现有代码来添加新特性。
10、依赖倒置原则（Dependency Inversion Principle, DIP）。类应当依赖于抽象而不是依赖于具体细节。