《Effective C++ 3th》——设计与声明

文章目录

友好的接口设计
member与non-member函数设计
不抛异常的swap函数设计

让接口容易被正确使用，不易被误用
设计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和removeCookiesprivate: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函数设计

略