一、类应该短小
类和函数一样应该短小。对于函数，我们通过计算代码行数衡量大小。对于类，我们采用不同的衡量方法，计算 权责。
类的名称应当描述其权责。实际上，命名正是帮助判断类的长度的第一个手段。如果无法为某个类命以精确的名称，这个类大概就太长了。类名越含混，该类越有可能拥有过多权责。例如，如果类名中包括含义模糊的词，如 Processor 或 Manager 或 Super，这种现象往往说明有不恰当的权责聚集情况存在。
1.1 单一权责原则
单一权责原则（SRP）认为，类或模块应有且只有 一条加以修改的理由。该原则既给出了权责的定义，又是关于类的长度的指导方针。类只应有一个权责——只有一条修改的理由。
public class SuperDashboard extends JFrame implements MetaDataUser
{
public Component getLastFocusedComponent()
public void setLastFocused(Component lastFocused)
public int getMajorVersionNumber()
public int getMinorVersionNumber()
public int getBuildNumber()
}
上述 SuperDashboard 类有两条加以修改的理由。首先，它跟踪大概会随软件每次发布而更新的版本信息。第二，它管理 Java Swing 组件（派生自 JFrame，顶层 GUI 窗口的 Swing 表现形态）。每次修改 Swing 代码时，无疑都要更新版本号，但反之未必可行：也可能依据系统中其他代码的修改而更新版本信息。
鉴别权责（修改的理由）常常帮助我们在代码中认识到并创建出更好的抽象。可以轻易地将全部三个处理版本信息的 SuperDashboard 方法拆解到名为 Version 的类中。Version 类是个极有可能在其他应用程序中得到复用的构造！
public class Version
{
public int getMajorVersionNumber()
public int getMinorVersionNumber()
public int getBuildNumber()
}
再强调一下：系统应该由许多短小的类而不是少量巨大的类组成。每个小类封装一个权责，只有一个修改的原因，并与少数其他类一起协同达成期望的系统行为。
1.2 内聚
类应该只有少量实体变量。类中的每个方法都应该操作一个或多个这种变量。通常而言，方法操作的变量越多，就越黏聚到类上。如果一个类中的每个变量都被每个方法所使用，则该类具有最大的内聚性。
一般来说，创建这种极大化内聚类是既不可取也不可能的；另一方面，我们希望内聚性保持在较高位置。内聚性高，意味着类中的方法和变量相互依赖、互相结合成一个逻辑整体。
如下 Stack 类的实现方法。这个类非常内聚。在三个方法中，只有 size() 方法没有使用所有两个变量。
public class Stack
{
private int topOfStack = 0;
List<Integer> elements = nes 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;
}
}
保持函数和参数列表短小的策略，有时会导致为一组子集方法所用的实体变量数量增加。出现这种情况时，往往意味着至少有一个类要从大类中挣扎出来。你应当尝试将这些变量和方法分拆到两个或多个类中，让新的类更为内聚。
1.3 保持内聚性就会得到许多短小的类
仅仅是将较大的函数切割为小函数，就将导致更多的类出现。想想看一个有许多变量的大函数。你想把该函数中某一小部分拆解成单独的函数。不过，你想要拆出来的代码使用了该函数中声明的4个变量。是否必须将这4个变量都作为参数传递到新函数中去呢？
完全没必要！只要将4个变量提升为类的实体变量，完全无需传递任何变量就能拆解代码了。应该很容易将函数拆分为小块。
可惜这也意味着类丧失了内聚性，因为堆积了越来越多只为允许少量函数共享而存在的实体变量。如果有些函数想要共享某些变量，为什么不让它们拥有自己的类呢？当类丧失了内聚性，就拆分它！
所以，将大函数拆为许多小函数，往往也是将类拆分为多个小类的时机。程序会更加有组织，也会拥有更为透明的结构。
二、构造函数
2.1 总述
不要在构造函数中调用虚函数，也不要在无法报出错误时进行可能失败的初始化。
2.2 定义
在构造函数中可以进行各种初始化操作。
2.3 优点
- 无需考虑类是否被初始化。
- 经过构造函数完全初始化后的对象可以为
const类型，也能更方便地被标准容器或算法使用。
2.4 缺点
- 如果在构造函数内调用了自身的虚函数，这类调用是不会重定向到子类的虚函数实现。即使当前没有子类化实现，将来仍是隐患。
- 在没有使程序崩溃 (因为并不是一个始终合适的方法) 或者使用异常 (因为已经被 禁用 了) 等方法的条件下，构造函数很难上报错误。
- 如果执行失败，会得到一个初始化失败的对象，这个对象有可能进入不正常的状态，必须使用
bool IsValid()或类似这样的机制才能检查出来，然而这是一个十分容易被疏忽的方法。 - 构造函数的地址是无法被取得的，因此，举例来说，由构造函数完成的工作是无法以简单的方式交给其他线程的。
2.5 结论
- 构造函数不允许调用虚函数。如果代码允许，直接终止程序是一个合适的处理错误的方式。否则，考虑用
Init()方法或工厂函数。 - 构造函数不得调用虚函数，或尝试报告一个非致命错误。如果对象需要进行有意义的 (non-trivial) 初始化，考虑使用明确的 Init() 方法或使用工厂模式。Avoid
Init()methods on objects with no other states that affect which public methods may be called (此类形式的半构造对象有时无法正确工作)。 - 不在构造函数中做太多逻辑相关的初始化。
三、结构体和类
仅当只有数据成员时使用 struct，其它一概使用 class。
在 C++ 中 struct 和 class 关键字几乎含义一样。我们为这两个关键字添加我们自己的语义理解，以便为定义的数据类型选择合适的关键字。
struct 用来定义包含数据的被动式对象，也可以包含相关的常量，但除了存取数据成员之外，没有别的函数功能。并且存取功能是通过直接访问位域，而非函数调用。除了构造函数，析构函数，Initialize()，Reset()，Validate() 等类似的用于设定数据成员的函数外，不能提供其它功能的函数。
如果需要更多的函数功能，class 更适合。如果拿不准，就用 class。
为了和 STL 保持一致，对于仿函数等特性可以不用 class 而是使用 struct。
注意：类和结构体的成员变量使用不同的命名规则。
四、继承
4.1 总述
使用组合常常比使用继承更合理。如果使用继承的话，定义为 public 继承。
4.2 定义
当子类继承基类时，子类包含了父基类所有数据及操作的定义。C++ 实践中，继承主要用于两种场合：实现继承，子类继承父类的实现代码；接口继承，子类仅继承父类的方法名称。
4.3 优点
实现继承通过原封不动的复用基类代码减少了代码量。由于继承是在编译时声明，程序员和编译器都可以理解相应操作并发现错误。从编程角度而言，接口继承是用来强制类输出特定的 API。在类没有实现 API 中某个必须的方法时，编译器同样会发现并报告错误。
4.4 缺点
对于实现继承，由于子类的实现代码散布在父类和子类间之间，要理解其实现变得更加困难。子类不能重写父类的非虚函数，当然也就不能修改其实现。基类也可能定义了一些数据成员，因此还必须区分基类的实际布局。
4.5 结论
所有继承必须是 public 的。如果你想使用私有继承，你应该替换成把基类的实例作为成员对象的方式。
不要过度使用实现继承。组合常常更合适一些。尽量做到只在 “是一个” (“is-a”, YuleFox 注: 其他 “has-a” 情况下请使用组合) 的情况下使用继承：如果 Bar 的确 “是一种” Foo，Bar 才能继承 Foo。
必要的话，析构函数声明为 virtual。如果你的类有虚函数，则析构函数也应该为虚函数。
对于可能被子类访问的成员函数，不要过度使用 protected 关键字。 注意，数据成员都必须是 私有的。
对于重载的虚函数或虚析构函数，使用 override， 或 (较不常用的) final 关键字显式地进行标记。较早 (早于 C++11) 的代码可能会使用 virtual 关键字作为不得已的选项。因此，在声明重载时，请使用 override， final 或 virtual 的其中之一进行标记。标记为 override 或 final 的析构函数如果不是对基类虚函数的重载的话，编译会报错，这有助于捕获常见的错误。这些标记起到了文档的作用，因为如果省略这些关键字，代码阅读者不得不检查所有父类， 以判断该函数是否是虚函数。
四、声明顺序
将相似的声明放在一起，将 public 部分放在最前。
类定义一般应以 public: 开始，后跟 protected:，最后是 private:。省略空部分。
在各个部分中，建议将类似的声明放在一起，并且建议以如下的顺序：类型 (包括 typedef， using 和嵌套的结构体与类)，常量，工厂函数，构造函数，赋值运算符，析构函数，其它函数，数据成员。
不要将大段的函数定义内联在类定义中。通常，只有那些普通的，或性能关键且短小的函数可以内联在类定义中。参见 内联函数 一节。
• 由 Leung 写于 2019 年 11 月 3 日
• 参考：Google 开源项目风格指南——3. 类
[代码整洁之道]
