[Effective C++ --018]让接口容易被正确使用，不易被误用

□第一节 什么是接口？
什么是接口？
百度百科的解释：两个不同系统(或子程序)交接并通过它彼此作用的部分。
接口的概念贯穿于整个软件开发过程中，本文讨论的接口概念仅局限于以C++实现的class，function等。

class接口
以OOP的思想，现实的问题总能抽象成一个个class，这些class包含哪些属性，方法其实就是class接口要考虑的问题。
function接口
class接口的操作就是通过一个个function来实现的，function的参数传递，返回值是function接口要考虑的问题。
本条款“让接口容易被正确使用，不易被误用” 是设计优良接口重要准则之一，并在开始的时候就需要考虑的。

“定义输入”
要开发一个“让接口容易被正确使用，不易被误用”的接口，首先要考虑使用该接口可能产生的错误。考虑用来表示时间的Date类。

class Date {
private:
    int   year;   //年份
    short month;  //月份
    short day;    //天数
public:
    Date(int year, short month, short day) {
        this->year = year;
        this->month = month;
        this->day = day;
    }
};

今天是2013/02/28，今天的日期可以表示为

Date d(,,);

那明天的日期可以表示为

Date d(,,);

问题来了，刚才手抖一下，把“03”敲成“13”。
还有一个问题，假如不小心也可能出现情况：

Date d(,,); //天数与月份反了

上面的两个问题系统都不会被系统检测，也就是我们的接口接收到错误输入而没有做出任何阻止。

“使用新类型”
导入新类型来覆盖已有的数据类型是一个不错的方案。

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

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

Date的构造函数可以是下面的样子：

Date(const Year& y, const Month& m, const Day& d);

Date d(Year(), Month(), Day()); // OK
Date d(Year(), Day(), Month()); // NG，类型错误

另外一个问题的解决很容易想到的方法是使用枚举：

关于年份，似乎输入任何一个数值都是合法的，所以不需要枚举。
关于月份，一年中只有12个月，所以可以枚举1~12的值。
比如月份的枚举如下：

enum Month {
    month1= ,
    month2,
    ...
    month12,
};

那么修改后的Date类应该是下面的样子

Date(Year year, Month month, Day day);

这样做法可以解决一部分问题，至少不会出现月份越界的情况。
于是明天的日期可以这么写：

Date d(Year(),month(3) , Day());

但很不幸C++中的枚举只是被拿来当作int值来用，例如下面的情况是可以通过编译的：

Date d(Year(), (Month), Day());

幸好，还有更厉害的一招:预定义所有有效的Months

class Month {
public:
     static  Month  Jan() { return Month(); }
     static  Month  Feb() { return Month(); }
    ...
    static  Month  Dec() { return Month(); }
private:
    explicit Month(int m);
}
Date d(Year(), Month::Feb(),Day());

但这种做法的看起来很诡异，而且当要枚举的集合中有很多元素时，势必影响到代码生产效率和系统性能。

总结
在接口设计的时候引入新类型，限定边界值是保证接口的正确性的有效措施之一。
但过分追求接口的正确性往往会带来系统逻辑复杂度的增加。

□第二节 让接口更容易些
“望文生义”
每个人都有名字，名字的作用就是用来区分个体的。名字往往能给我们带来很多信息。比如我的名字叫“小明”，很容易知道
我名字的读音“xiaoming”，是个男的。假如有个人叫“李芳”我说他是个男的，你信吗？

函数也有名字，这个名字是给人读的。所以当给接口定义名称的时候最好通俗易懂，"见名知意"。

“多重性”
用过.NET的都知道，Arrays有个属性名为Length用于求数组中元素个数，ArrayLists中有个属性为Count，也是干这事的。
相信肯定有过这样的经历：当使用元素个数的时候总是先尝试用Length，发现没有再换Count。是不是有点郁闷？

“自己动手”
有些事情自己能做，那就不要依赖别人。当接口的某些行为依赖于调用者来完成，那就犯了大忌。
比如我们的ConductorFactory，创建完Conductor就不管了。比如下面的代码：

cgi_CallStatus cgi_ConductorFactory::cgi_CreateSetSyslogConductor(cgi_SettingConductor *&conductor,
                                                                    cgi_Status &status)
{
    status.okNg = CALL_OK;

    conductor = MMI_NEW cgi_SettingConductor(
        cgi_Translate807a::Request,
        cgi_Translate807a::Response,
        cgi_Translate807a::GetSize,
        NULL,
        NULL,
        NULL);

    if (conductor == NULL) {
        cgi_TranslatorCommon::SetErrorStatus(CGI_ERROR_NEW, CGI_CONDUCTOR_FACTORY,
                                             CGI_FACTORY_SETSYSLOGCONDUCTOR, , status, NULL);
        return CALL_ERROR;
    }

    return CALL_OK;
}

conductor的销毁显然不是由ConductorFactory来负责，假如使用完没有delete，很显然内存泄漏就产生了。
我们可以使用智能指针来解决：

cgi_ConductorFactory::cgi_CreateSetSyslogConductor(std::tr1::shared_ptr<cgi_SettingConductor> conductor,  cgi_Status &status) {
...
}

什么是接口应该做的，什么是调用者要做的，在设计时一定要多加思考。

总结
容易理解的名字，一致的行为表现会让接口更容易使用，并且不会发生错误。接口尽量不要试图让调用者做些事情，因为它可能不听话。

■总结■
1.合理考虑接口的输入，并尽可能的阻止错误数据的输入
2.阻止错误的方法包括建立新类型，限制类型上的操作，束缚对象值，以及消除客户的资源管理责任
3.给接口一个容易理解的名字，告诉别人接口是干什么用的
4.让接口的功能与其行为保持一致
5.在系统中如果是做同一件事的，尽可能的保持接口名字的一致
6.尽可能少的期待调用者要做的事情，因为不能保证调用者会按照要求去做