C++感受14-Hello Object 封装版 - 上

1. 封装即约束——封装和派生、多态的本质区别

一门计算机语言，要如何帮助程序员写出优秀的代码？两个方法：一是给程序员更多能力，二是给程序员更多约束。之前我们学习的派生和多态，更多的是给我们技能，而封装，更多的是想约束我们。这就是封装和派生与多态最本质的区别。

简单复习下派生和多态：

• 派生——继承遗产
  派生可以让我们仅在基类拥有一个属性或实现一个功能，它的所有派生类以及派生类的派生类，就都将得到这个属性或功能，这很像现实生活中，子孙从祖辈那边继承到巨额财富的情况
• 多态——继承遗志
  多态则让在基类仅仅制定一个目标、或写下一个愿望，所有派生类就会各自努力去实现这个目标或愿望。这有点像父母们自己做不到的事（比如考上名校），却偏要为儿女后代们制定各种规矩——偏偏 ，后辈们还真的一个个努力实现了，不实现也可以，代价是：不实现祖辈遗愿的派生类，他们产生不了对象（莫非这就叫“无脸见人”？）

派生和多态还可以——事实上非常惯用——结合起来。以考上名校为例，基类可以自己先读上北大，而后它的派生类非常舒服：要么继承基类读北大的能力，要么嫌北大不好，改为努力去读清华……

就是这么舒服——这是因为派生和多态，本质是在给我们（程序员）能力。

但是今天我们要学习的面向对象的最后一个特性“封装”，就不是这样子了，相反，它总是想着法子来约束我们——严格讲，是希望我们多用它提供的各种办法，来自我约束。

2. 把约束封装成类型

2.1 海选报名的选手怎么定义？

假设在一个业务场景是 “选美大赛” 的项目代码中，你看到名为 “Person” 和 “Beauty” 的两个类型（比如struct），你会怎么想？

你肯定会有这样一个判断：Person 类型的对象，应该是有的长得好看，有的一般，而如果是 Beauty 类型的对象，就肯定得是美女。

正常来说，这个判定肯定是对的（当然，也有不正常的，比如 2024 年美国小姐选美，课堂视频里有它的冠军，希望你喜欢）。现在的关键问题是，作为程序员，你要如何保证 Beauty 类型产生的对象，在身材、长相（当然，应该也要包含心灵）都符合美女的要求？

在之前的课堂里，我们已经学习过 “类型即约束”，所以，一个 int 类型产生的对象（变量），它一定要能参加四则运算（扣除为零时不能作为除数的情况）……但是，像int、char、bool、float、double 这些都是语言内置类型，它们的约束，由语言硬性规定，而，当我们我们当上造物主，要如何让我们所创造的类型，拥有说一不二的约束力呢？

约束他人，先从约束自己做起。当我们写下一个结构的名字，名字不具备任何实质约束，就像现实生活中自称 “美女” 的人不一定美一样，我们必须往这个结构里添加字段——这就有了今天的第一个重要知识点：每当你往结构里加一个字段，你就是在为这个类型加一个约束，所以请保持克制。

就以这个 Person 为例，在程序世界里，如果它不拥有任何字段，那么，Person 类型对它的对象就没有任何要求（约束）。意思是，世间任何事物都可以映射到这个程序中的“人类”定义——一块石头也可以自称是人类。而一旦加了字段，就开始产生要求。比如，加上 “性别”，那么，无性繁殖的事物，就不可能成为这个程序中的人类对象。

继续以 “选美” 大赛为例，我们让需求再明确一些：希望用 Person 来表达选美赛海选阶段来报名的选手，那么，我们可以或者需要在 Person 中加入什么约束呢？这事不能光听老板，或者迷信技术大佬，我们得听具体的业务要求。

假设，本次海选有这么一条规则：选手必须是女生，但是在海选阶段，我们也非常欢迎 “伪娘”前来报名……

• 为什么有这么矛盾的需求？

组委会说了，这样才容易产生有利宣传的噱头，以求在海选阶段引发更多关注……

所以，Person 类型至少需要有个“性别”字段，而一旦有性别字段，就意味着漂亮的灯塔水母，它们受到约束，无法报名了……

• 灯塔水母虽为“母”，但它们其实是无性动物……
  

接着，假设报名的海选评比，对选手的身高有要求，那么，就得为 Person 类加上身高字段，同理、我们还要检查体重、还要检查年龄……于是：

// 海选报名选手类定义的伪代码
struct Person
{性别身高体重年龄
};

切记：类型所拥有的每一样属性，都是这个类型在表达的一个约束。

2.2 海选胜选后的美女，怎么定义？

我们让业务继续发展：如何定义那些通过海选成功进入二选的选手？

常见的错误思路：让 Person 通用一点，既可以表达海选选手，也可以表达二选选手。这种想法，根源上可能是想让某个类型具备更好的可复用性。

同一事物放在A处也能用，放在B处也能用，这是对 “复用” 的侮辱。请理解，类型具有好的可复用性和代码具有好的可复用性的区别。

假设二选考核指标为三围数据，那么按上面的思路，就应该在 Person 中加入三围数据：

// 让 Person 变得 “通用” 的思路下，Beauty 的定义（伪代码）
struct Person
{性别身高体重年龄胸围、腰围、臀围
};

这就叫作程序设计中的“放纵”，现在，当一个 Person 对象用于表达普通选手时，用户（程序员，包括你自己）需要记住：此时三围数据没什么用，更糟糕的是，除非看代码的上下文（包括注释），否则一个用户（程序员，包括你）只看到某个 Person 对象，他很容易陷入这样一个困境：我必须清楚这个 p 的真实身份，偏偏代码写得让人很难清楚。

解决办法有两种：一是让功能可以复用，同时对象有清楚的类型，这种方法叫“继承/派生”；二是让功能可以复用，同时用户（程序员，包括你）可以不去关心它的具体身份类型，这种方法叫“多态”。

先来看第一种方法：派生。

// 派生的好处：又复用，又类型明确 （伪代码）
struct Person
{性别身高体重年龄
};struct Beauty : Person
{胸围、腰围、臀围
}; 

现在，Person 类型并不具备可复用性，它无法用来定义一个通过海选的选手，但是 Person类定义这段代码被很好地复用了——以 基类的形式被派生类使用——并且，这种复用，Person类本身毫不知情。

小节知识点

编程时，往类型定义里添加字段，就像做菜时往菜里倒调料：加时容易，想再挑出来就难了。

3.成员访问控制的约束

成员访问控制，用来控制类型的成员（包括成员数据和成员函数）的可访问范围。C++分了三级：

• public（公开的）
• protected（受保护的）
• private（私有的）

为什么要加成员访问控制？假设海选阶段报名选手的类型最终定义如下：

struct Person
{int no;		// 编号std::string name;   // 姓名int gender; 	// 性别(0女,1男)int age;        	// 年龄int height; 	// 身高int weight;		// 体重
};

然后有一个报名函数，用于登记选手信息，代码如：

void 报名()
{Person a; // 构造时，选手会输入自己的各项信息登记(a); // 将当前选手登记到大赛系统中a.gender = 0; // ???...
};

报名函数打问号那行显得非常可疑，怎么会登记之后突然又去设置选手性别呢？这是要让选手在报名大厅里现场做变性手术吗？

显然，需要有个手段来约束这种行为，约束程序员不要这样不分场合地 “动” 一个对象的内部数据。“成员访问控制” 就是方法之一，并且是主流的面向对象语言中提供这种约束的最常用的方法。

对于类而言，访问控制围绕代码的位置展开，有三类位置：

1. 【位置一】当前类的内部，包括类定义内部（类定义的那对{}内部），以及类成员函数内部（类成员函数体的那对{}内部）；
2. 【位置二】当类的派生类内部；
3. 【位置三】类外部，即当前类之外，包括其它类（但不是派生类）或所有类之外的位置，比如自由函数。

对应到三级访问权限控制：

• 加 private 修饰的成员，只能在类内部中直接访问（包括读和写，下同）；
• 加 protected 修饰的成员，只能在类内部和派生类内部中直接访问；
• 加 public 修饰的成员，可以类内、类外访问，即位置一、二、三都可直接访问。

struct 的成员，如果不加任何访问控制修饰，就是 public 的。之前我们定义 struct 时，并没有写什么访问控制，但都可以在结构外部直接访问，比如上面 “报名” 函数的例子：在自由函数中直接访问 a 对象的 gender 数据。

C++为成员添加访问控制的具体写法是：在成员前面写上控制级别的关键字，并加一个冒号。则：从冒号往后直到类定义结束，或者遇到另一个访问控制关键字，其间所有成员（包括成员数据或成员函数），都拥有所指定级别的访问权限。

示例：想让 Person 的所有数据，都无法在外部访问（包括读或写），写法是：

struct Person
{
private:int no;		// 编号std::string name;   // 姓名int gender; 	// 性别(0女,1男)int age;        	// 年龄int height; 	// 身高int weight;		// 体重
};

现在，在 Person 之外，我们改不了对象的性别等数据。不过，新的问题产生了：现在我们连查询 Person 对象的性别也做不到了（其它如年龄、身高、体重也一样无法获知）——这显然无法满足举办选美大赛的需求。总不能让评委在问选手 “芳龄几何” 时，得到一个白眼吧？

解决方法是加上相应的查询方法，并且这些方法设定为 public；这样数据是私有的，但方法是公开的。外界可以通过公开的查询方法来获得信息，同时保证“只看不动”，不会修改信息：

struct Person
{
public:int GetNo() { return no; } 	// 查编号std::string GetName() { return name; } // 查姓名int GetGender()  { return gender; }  // 查性别... // 这边还有很多 GetXXX()
private:int no;std::string name;int gender;int age;int height;int weight;
};

应用例子：

void 报名()
{Person p; // 在 Person 外调用其 public 成员函数if (p.GetGender() != 0) cout << "你不是女生哦！" << endl;
}

4. 常量成员函数的约束

之前我们学过“常量”。当时说的是数据。当一个数据是常量，那么这个数据必须在定义的时候就确定值，且固定此但值，不让修改。

在类型定义中，我们也可以定义某个成员数据是常量，称其为 “常量成员数据”。特别地，在我们这个例子中，性别字段就很适合定义成 “常量成员数据”。除非大赛想允许选手在参赛期间变性，否则，一个人的生理性别确实应该在胚胎形成阶段就确定下来，并不再改变。

作为“快速感受也探索”之旅的课堂，我们并不在这节课细讲常量成员数据这种更加严厉的约束手段，我们重点讲更常见的一种约束：“常量成员函数”。

下面代码中，GetName() 这个成员函数的实现非常邪恶：

struct Person
{
public:std::string GetName() { gender = 1 - gender; // 邪恶的代码在这行！！！return name; }int GetGender()  { return gender; }... // 更多公开方法，略
private:int no;		std::string name;  int  gender; 	... // 更多私有数据，略
};

每当我们查询某个选手的姓名，这个选手就会立刻暗地里变性一次！这次男变女，下次女变男……

显然，我们对自己的约束，还是不够……怎么办？只见C++像多啦A梦一样，从肚兜里掏出一条麻绳，不对，是掏出一个语言特性：常量成员函数。

只要在类成员函数的头和体之间，加上 const 修饰，这个成员函数就会变成常量成员函数。效果则是：在它的内部，以及它所调用的当前类（包括从基类继承而得的）的其他函数中，都不允许修改到当前类（包括从基类继承而得的）成员数据。

仍以 GetName() 成员为例：

struct Person
{
public:std::string GetName() const // <-- 常量成员函数{ gender = 1 - gender; // 编译失败!!!return name; }int GetGender()  { return gender; }... // 更多公开方法，略
private:int no;		std::string name;  int  gender; 	... // 更多私有数据，略
};

现在，如果邪恶的程序员改为在 GetGender() 里偷偷摸摸修改性别，然后在常量版本的 GetName() 里调用 GetGender()，是不是也能犯下 “查询选手姓名时令选手变性” 的罪行呢？放心，不会的。当一个函数是成员函数，那么它能调用的成员函数（包括自身或继承所得），都必须也是常量成员函数。套用到到本例，就是 GetGender() 也必须是常量成员函数。

事实上，正确设计往往就是自然而然的设计：类的所有查询信息的操作，都不应该修改类的内部数据。

女神本来很饿，你过来问一句：“吃了吗？要不要一起晚餐？”，她答：“吃过了，谢谢！”。这种事情在生活中我帮不了你，但是在C++中，可以通过常量成员函数来避免。

5. 从struct到class，越成长，越懂得自我约束

5.1 语法差别

从功能上讲，struct 和 class 完全可以互相替代 。在语法作用上，它们的差别也很少，主要两点：

• struct中成员的默认访问控制是 public，而 class 则默认是 private;
• struct作为派生类时，默认的派生方式是公开派生，而class默认是私有派生。

第二点我们在后面的课堂会再谈到。现在就看第一点，请对比：

5.2 何时 struct 何时 class？

重点在语义区别，一个类型，什么时候适合用 struct 表达，什么时候适合用 class 表达呢？

这个问题没有标准答案，但是有一些流行的约定。我们来介绍两种。

• 方法一：数据有联动修改关系，用 class，否则用 struct

什么叫联动关系？ 就是一个成员数据发生变化后，如果可能引起另外一个成员数据也发生变化，就叫作二者间存在联动修改关系。

联动修改关系在判断上又分为宽松版和严格版。在对象初始化过程中，字段间所存在互相影响的关系如果算联动，就叫严格版，否则为宽松版。

听起来有点不太好理解？来看实例：还是 Person(人类）的定义，我们把它简化到只包含姓名和性别。父母在为之取名时，肯定会考虑宝宝的性别因素——如果认为这种对象初始化过程的互相影响也算是数据间存在联动修改关系，这种判断方法叫严格版，否则叫宽松版。

实际工作中我喜欢宽松版。不过，今天我们的重点是另一种方法，它显得又简单又粗暴：

• 方法二：用到非公开（public）成员，就用 class 定义。

也就是说，如果你所定义的类型中，存在不想被公开访问的成员数据或函数，那么，用这个方法，你就将得到一个class而不是一个struct。

6. 课堂视频

视频和文字教程，一定结合学习，效果好太多。

ff17-HelloObject-封装版-上