条款18：让接口容易被正确使用，不易被误用

  欲开发一个“容易被正确使用，不容易被误用”的接口，首先必须考虑使用者可能做出什么样的错误。假设你为一个用来表现日期的class设计构造函数：

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

    乍见之下这个接口通情达理。但是它的使用者很容易犯下至少两个错误。第一，他们也许会以错误的次序传递参数：

Date d(30, 3, 1995);

  第二，他们可能传递一个无效的月份或天数：

Date d(2, 30, 1995);

  许多客户端错误可以因为导入新类型而获得预防。既然这样，就让我们导入简单的外覆类型来区别天数、月数和年份，然后于Date构造函数中使用这些类型：

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

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

struct Year{
explict 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,类型正确

  令Day，Mouth和Year成为成熟且经充分锻炼的classes并封装其内数据，比简单使用上述的structs好。但即使structs也已经足够示范：明智而小心导入新类型对预防“接口被误用”有神奇疗效。

  一旦正确的类型就定位，限制其值有时候是通情达理的。例如一年只有12个有效月份，所以Mouth应该反映这一事实。办法之一是利用enum表现月份，但enum不具备我们希望拥有的类型安全性，例如enums可被拿来当一个ints使用。比较安全的解法是预先定义所有有效的Months：

class Month{
public:
    static Month Jan() { return Mouth(1); } //函数，返回有效月份
    static Month Feb() { return Month(2); }
    ...
    static Month Dec() { return Month(12); }
    ...
private:
    explict Month(int m);            //阻止生成新的月份，这是月份专属数据
    ...  
};

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

  tr1::shared_ptr提供的某个构造函数接受两个实参：一个是被管理的指针，另一个是引用次数变为0时被调用的“删除器”。这启发我们创建一个null tr1::shared_ptr并以getRidOfInvestment作为其删除器，像这样：

std::tr1::shared_ptr<Investment> pInv(0, getRidOfInvestment); //企图创建一个null shaerd_ptr
                                                              //并携带一个自定的删除器                  
                                                              //此式无法通过编译

  tr1::shared_ptr构造函数其第一参数必须是个指针，而0不是指针，是个int。是的，它可被转换成指针，但在此情况下并不够好，因为tr1::shared_ptr坚持要一个不折不扣的指针。转型（cast）可以解决这个问题：

std::tr1::shared_ptr<Investment> pInv(static_casst<Investment*> (0),
                            getRidOfInvestment);//建立一个null shaerd_ptr并以            
                                                //getRidOfInvesment为删除器

  因此，如果我们要实现createInvestment使它返回一个tr1::shared_ptr并夹带getRidOfInvestment函数作为删除器，代码看起来像这样：

std::tr1::shared_ptr<Investment> createInvesment(){

    std::tr1::shared_ptr<Investment> retVal(static_cast<Investment*>             (0)),getRidOfInvestment);

    retVal = ...;                   //令retVal指向正确对象

    return retVal;
}

 

 

  结论：

    好的接口很容易被正确使用，不容易被误用。你应该在你的所有接口中努力达成这些性质。

   “促进正确使用”的办法包括接口的一致性，以及与内置类型的行为兼容。

   “阻止误用”的办法包括建立新类型、限制类型上的操作，束缚对象值，以及消除客户的资源管理责任。

   tr1::shared_ptr支持定制性格删除器。这可以防范DLL问题，可别用来自动解除互斥锁等等。