参考资料:
- 《Effective C++》第三版
注意:《Effective C++》不涉及任何 C++11 的内容,因此其中的部分准则可能在 C++11 出现后有更好的实现方式。
条款 18:让接口容易被正确使用,不易被误用
好的接口很容易被正确使用,不容易被误用。你应该在你的接口里努力达成这一性质
理想状态下,应该在编译期发现客户对接口的误用。
“促进正确使用”的办法包括接口的一致性、以及与内置类型的行为兼容
如果没有特殊理由,尽量令你的 types 和内置类型保持一致。
“阻止误用的办法”的办法包括建立新类型、限制类型上的操作,束缚对象值,以及消除客户的资源管理责任
假设我们有设计一个用来表示日期的类:
class Date {
public:Date(int month, int day, int year);
private:int month, day, year;
};
这样的接口是很容易被误用的:
Date(30, 3, 2024); // 错误的参数传递顺序
Date(2, 30, 2024); // 错误数据范围
一种常见的预防方法是导入新类型:
class Month {
public:explicit Month(int val);
private:int val;
};class Date {
public:Date(const Month &m, const Day &d, const Year &y);...
};Date(Day(30), Month(3), Year(2024)); // 编译错误
设计了类型,就可以限制每个类型的合法值,比较安全的做法是预先用函数定义有效值:
class Month {
public:static Month Jan() { return Month(1) }...
private:explicit Month(int val); // 私有构造函数,避免用户调用
};Date(Month::Jan(), day(30), Year(2024));
如果我们的接口要求客户必须“记得某些事情”,就是有着“不正确”使用的倾向,例如下面的工厂函数, 返回一个指针指向动态分配对象:
A* createA(...);
为了避免资源泄露,客户可以将 createA
返回的指针保存在智能指针中,但客户可能会忘记这一点,所以我们最好令工厂函数直接返回智能指针:
shared_ptr<A*> createA(...);
shared_ptr
支持定制删除器, 可以防范 DLL 问题
shared_ptr
有一个特别好的性质:它会自动使用它所管理指针的专属删除器(自定义的删除器或默认的 delete
),这可以解决“cross-DLL problem”。“cross-DLL problem”指:对象在一个动态链接库(DLL)被 new
创建,在另一个 DLL 被 delete
销毁。
条款 19:设计 class 犹如设计 type
Class 的设计就是 type 的设计,在定义一个新 type 之前,请确定你仔细思考过本条款覆盖的所有讨论主题
每次设计 class 时,需要考虑如下问题:
- 新 type 的对象应该被如何创建和销毁?
- 对象的初始化和对象的赋值该有什么样的差别?
- 新 type 的对象如果被 passed by value,意味着什么?
- 什么是新 type 的“合法值”?
- 你的新 type 需要配合某个继承体系吗?
- 你的新 type 需要什么样的转换?
- 什么样的操作符和函数对此新 type 而言是合理的?
- 什么样的标准函数应该被驳回?
- 谁该取用新 type 的成员?
- 什么是新 type 的未声明接口?
- 你的新 type 有多么一般化?
- 你真的需要一个新 type 吗?
条款 20:宁以 pass-by-reference-to-const 替换 pass-by-value
尽量以 pass-by-reference-to-const 替换 pass-by-value。前者通常比较高效,并可避免切割问题
考虑下面的例子:
class A{
public:...
private:string a, b ,c;
}void func(A a);
执行 func
在参数构造时需要调用 A
的 copy 构造函数,进而需要调用 3 个 string
的 copy 构造函数,执行结束后,这些对象还要析构。更高效的方法是,使用 pass-by-conference-to-const,避免了对象的构造和析构,同时 const
也保证 func
不会对传入的对象进行修改。
pass-by-reference-to-const 还可以避免切割问题:
void func(base b){b.f(); // 调用base::f()
}void func(cosnt base &b){b.f(); // 根据实际传入的类型执行不同版本的f()
}
以上规则并不适用于内置类型、STL 的迭代器和函数对象。对它们而言,pass-by-value 比较合适
引用的底层实现往往是指针,所以对于内置类型,pass-by-value 往往比 pass-by-reference-to-const 更高效。此外,STL 的迭代器和函数对象习惯上实现为 pass-by-value,STL 的实现者保证了高效性和避免出现切割问题。
需要注意的是,不能因为内置类型适合 pass-by-value,就认为和内置类型一样小的对象适合 pass-by-value,原因是:
- 对象小不一定意味着构造函数不昂贵。
- 编译器对待内置类型和自定义类型的方式截然不同,例如某些编译器会把
double
对象放入缓存中,却拒绝把只含有一个double
成员的自定义对象加入缓存。 - 自定义对象的大小容易有所变化。
条款 21:必须返回对象时,别妄想返回其 reference
绝不要返回 pointer 或 reference 指向一个 local stack,或返回 reference 指向一个 heap-allocated 对象,或返回 pointer 或 reference 指向一个 local static 对象而有可能同时需要多个这样的对象
考虑我们有一个表示有理数的类,重载了 *
:
class Rational {
public:Rational(int n, int d);// 试图by reference返回值friend const Rational &operator*(const Rational &lhs, const Rational &rhs);
private:int n, d;
};
返回指向 local stack 的 pointer 或 reference,由于 local stack 对象在函数返回的时候就已经被销毁了,所以任何使用返回值的行为都将导致未定义行为。
返回指向 heap-allocated 的 pointer 或 reference,调用者很容易忘记 delete
,很容易造成内存泄露。
如果考虑定义一个静态 Rational
对象专门保存结果,不仅会在多线程产生不安全的问题,有时还会造成逻辑错误:
bool operator==(const Rational &lhs, const Rational &rhs);
Rational a, b, c, d;
if ((a * b) == (c * d)) {...
}
由于 a*b
和 c*d
返回的是同一个静态变量,所以条件永远成立。
条款 22:将成员变量声明为 private
切记将成员变量声明为 private
,这可赋予客户访问数据的一致性,可细微划分访问控制、允诺约束条件获得保证,并提供 class 作者以充分实现弹性
所有成员变量都不该是 public
:
- 从语法一致性的角度来看,所有变量不是
public
,意味着所有接口都是函数,此时用户就不需要纠结是否应该使用小括号。 - 使用函数可以让你对成员变量有更精确的控制:通过函数可以实现“不可访问”、“只读访问”、“只写访问”、“读写访问”等。
- 从封装性的角度来看,将成员变量隐藏在函数接口的背后,可以使实现更加灵活,如:在成员变量被读写时进行记录、验证成员变量是否满足约束条件等。此外,不封装通常也意味着不可改变,将成员变量隐藏,就保留了优化的空间。
protected
并不比 public
更具封装性
使用 protected
虽然相比 public
可以实现语法一致和精确控制,但其封装性却并不比 public
强。
成员变量的封装性,与改变(例如:从 class
中移除)这个成员变量所破坏的代码量成反比。对于 public
变量,一旦其被移除,所有使用它的用户代码都会被破坏;对于 protected
变量,一旦被移除,所有使用它的 derived class 代码都会被破坏,二者都会造成不可预知的大量代码受到破坏。
所以,从封装的角度来看,只有 private
(封装)和其他(不封装)。