C++设计与声明——让接口容易被正确使用

一个简答易错的例子##

class Date
{
public 
    Date(int month,int day,int year);
}

一年后使用这个接口的时候，写了Date d(15,10,2015)或者Date d(2015,10,15)，准确的应该是Date d(10,15,2015)，欧，多么低级的错误，花了我一个早上的时间去调试这个bug。

解决的方法###

为参数声明自定义类型

struct Day    
{
    explicit Day(int d):val(d)
    {}
    int val;
};
struct Month    
{
    explicit Month(int d):val(d)
    {}
    int val;
};
struct Year    
{
    explicit Year(int d):val(d)
    {}
    int val;
};
class  Date
{
public:
	 Date(const Month& m,const Day& d,const Year& y);
};
Date d(30, 3, 1995);    //wrong
Month m(10);
Day m(15);
Year y(2015);
Date(y, m, d);	        //wrong
Date(m, d, y);	        //right

这样子声明类型会很麻烦，但是对“接口被误用”却又神奇的疗效

使用预先定义的类

class Month
{
public:
    static Month Jan()
    {
        return Month(1);
    }
    ...
private:
    explicit Month(int m);
    ...
};

通过函数返回我们需要的月份，保证参数的正确性。

PS：上面使用函数返回，是为了保证使用的月份实例已经初始化

自定义类型与内置类型保持一致

常见的方法有：加上const。再来一个易错的例子

class INT
{
public
    INT(int);
    INT opeaator=(INT);
    INT operator*(INT);
    int val;
};
    if(a*b = c)
    {...}

我们重新定义了系统的int类型，却发现，在a * b = c成功地通过了编译阶段，这个时候要想不进入if下的程序块真的是难上加难，这很明显违背我们的初衷。假如operator*返回的是const，那么就会限制a * b = c的执行。其实，这只是与内置类型的int符合罢了。所以，自定义的type应该尽量内置类型保持一致，除非我们有个好理由（其实一般我们也找不到这种理由）。

保持接口一致化

假如string使用Length，List使用size返回内部的对象个数，你是不是每次使用的时候都要考虑一下要使用Length还是size？假如不想自己的心灵饱受折磨，请保持功能一致的接口使用方法一致。

在客户之前预防客户的错误

假如createInvestment()返回一个Investment类型的指针给客户，谁也无法保证客户使用完了会正确地释放内存。所以较佳的做法是，先发制人，强迫客户使用智能指针，将返回值修改为std::tr1::share_ptr< Investment >createInves()给客户，这基本消除了发生内存泄露的可能性。

假如客户希望通过getRidOfInvestment()来删除指针，但却希望客户自己完成这件事，那又多了一个通往错误的大门。我们可以在返回智能指针前就先指定好删除器，以免客户遗忘。

std::tr1::shared_ptr< Investment> createInvestment()
{
    std::tr1::share_ptr< Investment> retVal(static_cast< Invesment*>(0),
    getRidOfInvestment);
    retVal = ...;    //令retVal指向正确的对象
    return retVal; 
}

上面的例子中，就算用户忘记了释放内存，最后智能智能share_ptr也会根据getRidOfInvestment正确地释放，从而减少了内存泄露的可能性。

实际上，使用了share_ptr的好处不仅仅如此。当使用了dll的时候，假如在一个dll中获得了指针，在另一个dll中依然能通过原来的dll对指针进行删除。从而用户无需在意cross dll problem的问题。