Effective C++ - Designs and Declarations

前言：软件设计，是令软件做出你希望它做的事情的步骤和做法。通常以颇为一般性的构想开始，最终演变成十足的细节，以允许特殊接口的开发。这些接口而后必须转换为C++声明式。而如何实现良好C++接口的设计和声明呢？通常的一个准则是：“让接口容易被正确使用，不容易被误用”。

---

1 Make interfaces easy to use correctly and hard to use incorrectly

理想上，如果客户企图使用某个接口而却没有获得他所预期的行为，这个代码不该通过编译；如果代码通过了编译，它的作为就该是客户所想要的。

一个例子：假设你为一个用来表现日期的class设计构造函数。

class Data {
public:
    Data(int month, int day, int year);
    // ...
};

咋见之下，这个接口通情达理（至少在美国如此），但它的客户很容易犯下至少两个错误。
1. 他们也许会以错误的次序传递参数。
2. 他们可能传递一个无效的月份或天数。

好的做法：
许多客户端错误可以因为导入新类型而获得预防。在防范”不值得拥有的代码”上，类型系统（type system）是你的主要同盟国。既然这样，我们可以导入简单的外覆类型（wrapper types）来区别天数，月份和年份，然后于Data构造函数中使用这些类型。

struct Day {
explicit Day(int d) : val(d) {}
int val;
};

struct Month {
explicit Month(int m) : val(m) {}
int val;
};

struct Year {
explicit Year(int y) : val(y) {}
int val;
};

class Date {
public:
    Date(const Month& m, const Day& d, const Year& y);
    // ...
};

Date d(30, 3, 1995);                   // 错误，类型不匹配
Date d(Day(30), Month(3), Year(1995)); // 错误，类型不匹配
Date d(Month(3), Day(30), Year(1995)); // OK 

可见，明智而审慎地导入新类型对预防”接口被误用”有神奇疗效。但是，当保证了正确的类型后，如何限制其合理的值呢。例如，一年只有12个月，所以Month应该反映这一事实。一个办法是利用enum表现月份，但enum不具备我们系统拥有的类型安全性，例如，enum可被拿来当一个int使用。比较安全的做法是，预先定义所有有效的Month。

class Month {
public:
    static Month Jan() { return Month(1); }
    static Month Feb() { return Month(2); }
    // ...
    static Month Dec() { return Month(12); }

private:
    explicit Month(int m);   // 阻止生成新的月份
};

Date d(Month::Mar(), Day(30), Year(1995));

其他预防方法还包括：

1. 限制类型内什么事可做，什么事不能做。常见的限制是加上const。
2. 除非有好理由，否则应该尽量令你的types的行为与内置types一致。
3. 提供行为一致的接口。STL容器的接口十分一致（虽然不是完美地一致），这使它们非常容易被使用。例如，每个STL容器都有一个名为size的成员函数，它会告诉调用者目前容器内有多少个对象。有些开发人员会以为IDE能使这些不一致变得不重要，但他们错了。不一致性对开发人员造成的心理和精神上的摩擦与争执，没有任何一个IDE可以完全抹除。