让接口容易被正确使用,不易被误用
设计class犹如设计type
宁以pass-by-reference-to-const替换pass-by-value
必须返回对象时,别妄想返回其reference
将成员变量声明为private
宁以non-member、non-friend替换member函数
若所有参数皆须类型转换,请为此采用non-member函数
考虑写出一个不抛异常的swap函数
友好的接口设计
引入类:
class Time
{
public:
Time();
~Time();
Time* createTime();
...
void setTime(int hour, int minute, int second);
...
};
一切都是为了接口的友好,必须要考虑以下两个问题:
- 用户可以给什么?
- 可以给用户什么?
用户可以给什么即用户的参数怎么传递,如何通过参数的结构化设计来避免用户传参时的茫然。针对 setTime
函数:
// 普通设计
void setTime(int hour, int minute, int second) {...}
// 参数结构化
struct HOUR {...} // 或 enum HOUR {...}
struct MINUTE {...} // 或 enum MINUTE {...}
struct SECOND {...} // 或 enum SECOND {...}
void setTime(HOUR hour, MINUTE min, SECOND sec);
通过对参数封装实现输入参数限制,接口更友好。但这种设计是否必要?我不禁想起各种开源的神级软件,例如ffmpeg、vlc等等不胜枚举,参数真的是晦涩…此外,增加函数内部检查即可有效避免参数错误情况,不过如果是做开放API则遵循这些友好建议是相当不错的。
可以给用户什么如出一辙,针对 createTime
函数,创建的对象指针最后需要被释放,为了避免忘记可以将对象指针放入智能指针,但何不一开始 createTime
就直接返回智能指针呢?
唔,这种强烈交互性需求必然要求像设计C++内置type一样去设计自己的类。这对于大众码农来说当然是很高的要求了,不然何不写个自己的语言呢?
封装层面的暂且不说,来谈谈性能层面。
int compare(Time tm) {...}
int compare(const Time &tm) {...}
区别在哪?Time tm
会在传递过程中产生临时变量和复制操作,而 const Time &tm
则不会产生额外变量,可以减少的性能耗费当然是尽量减少了。之前网上不少网友因为 std::string
作为参数传递为什么要传 const std::string &
而大打出手,Qt那边也有 QString
与 const QString &
相同疑问,想必这样应该会对 使用引用传递替代值传递 有更加深刻的认识。
再看:
const Rational& operator*(const Rational &lhs, const Rational &rhs)
{
Rational result(lhs.n * rhs.n, lhs.d * rhs.d);
return result;
}
const Rational& operator*(const Rational &lhs, const Rational &rhs)
{
Rational *result = new Rational(lhs.n * rhs.n, lhs.d * rhs.d);
return *result;
}
这些都是翻车代码,返回给用户的都是埋雷的引用。情况一的result由stack分配,函数返回时它的内存理当销毁,那要它的引用有何用?情况二的result确实由heap分配,但谁负责销毁?
member与non-member函数设计
考虑程序:
class WebBrowser
{
public:
...
void clearCache();
void clearHistory();
void removeCookies();
...
// member封装调用
void clearEverything(); // 调用clearCache、clearHistory和removeCookies
private:
bool cleared; // 成员变量应尽量private
};
// non-member封装调用
void clearBrowser(WebBrowser &wb)
{
wb.clearCache();
wb.clearHistory();
wb.removeCookies();
}
member封装调用和non-member封装调用哪个好?non-member函数允许对WebBrowser相关机能有较大的包裹弹性,可增加WebBrowser的可延展性。
事实上,WebBrowser提供网络访问的最基本封装,而clear操作则是针对WebBrowser的业务封装,建议将这两部分的代码独立出来。而如果非要选择的话还是non-member更好些,除非提供额外的类来替代non-member的功能。
其次,变量成员都声明成 private
也并非必须,不能说 public
的改动可能波及范围大就摒弃 public
和 protected
型的成员变量,在没有明确期望成员变量何时可见的时候,我们不妨使用中庸的 protected
,而当目标明确的时候,限定符的选择自然也就不会成为问题。
针对算术运算的member与non-member比较:
class Rational
{
public:
...
const Rational operator*(const Rational &rhs) const; // member
...
};
// non-member
const Rational operator*(const Rational &lhs, const Rational &rhs)
{
return Rational(lhs.numerator() * rhs.numerator(),
lhs.denominator() * rhs.denominator());
}
此时的member并不能完全实现混合运算,而non-member声明的函数却可以:
// member
Rational oneEighth(1, 8);
Rational oneHalf(1, 2);
Rational result = oneHalf * oneEighth; // success
result = result * oneEighth; // success
result = oneHalf * 2; // success
result = 2 * oneHalf; // error
// non-member
result = oneHalf * 2; // success
result = 2 * oneHalf; // success
这是因为member只是属于类的操作符重载,由类主导;而non-member对两个操作数平等对待,自然可以对所有参数进行隐式的类型转换。
总结而言:针对功能需求合理选择member与non-member函数实现。
不抛异常的swap函数设计
略