【复读EffectiveC++18】条款18：让接口容易被正确使用，不容易被误用

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

开发者要注意，你的功能要尽全力去减少不确定性 。

一、有什么问题

取原书的例子：
存在一个日期类，他的本意是用来记录年月日的，因此构造函数就有着年月日三个入参；

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

现在考虑创建这个日期类的，这里会出现一个问题：

Date d(30, 3, 1995);    // 不存在30天
Date d(2, 30, 1995);   // 2月没有30天

这类错误数据其实很常见，它的成因，有可能是入参看错，有可能是不知 “ 常识 ” ，但归根结底就是，使用限制不明确。
我们无法强求用户，只能尽力限制住，用户什么不可以。

二、怎么解决

1、方法一

最笨的方法可以是：

Date::Date(int month, int day, int year)
{
	if(month == 2 && day >= 30)
		return;
	
	处理代码
	
}

在函数内部，具体的处理代码之前进行判断，如果出现不想要的情况就提前返回；
但，这种方法，只是治标不治本，穷举全部不想要情况，还是尽量作为一种辅助手段。

2、方法二

enum eMonth
{
	eMonth_Jan，
	eMonth_Feb，
	...
};

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

Date d(eMonth_Jan, 30, 1995); 

使用枚举类型就进行限制，就可以很好的限制住像月份这样明确且有限的数据输入，保证使用者，不会给你写进去一个第30月进去，但也要考虑，日怎么写，用枚举？那要是输入限制在1-10000内的日也用枚举，那就不用干别的了。

3、方法三

许多客户端错误可以通过导入新类型预防。我们可以导入简单的外覆类型（wrapper type）来区别天数、月份、年份，然后于Date构造函数中使用这些类型：

class Month
{
public:
    static Month Jan()    // 函数，返回有效月份，稍后解释为什么使用函数而非对象
    {
        return Month(1);
    }
    
    static Month Feb()
    {
        return Month(2);
    }
    // ...
    static Montn Dec()
    {
        return Month(12);
    }
    // ...    其他成员函数

private:
    explicit Month(int m);    // 阻止生成其他月份，这是private的
    // ...
};

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

Date d(Month::Jan(), 30, 1995); 

如此设计，也可以达到相同的防御效果。

三、拓展问题

Investment *createInvestment();

当有这样一个返回值为一个指针的接口，我们在使用的时候，就要注意别忘了用完就释放，但总会有人忘记释放；
因此，我们作为设计者，这种释放问题也是要防御的点，也是要限制住的。

要怎么做呢？

std::tr1::shared_ptr<Investment> createInvestment();

强迫用户使用智能指针不失为一种好选择。

四、总结

1、好的接口很容易被正确使用，不容易被误用。你应该在你的所有接口中努力达成这些性质。
2、促进正确使用的方法包括接口的一致性，以及与内置类型的行为兼容。
3、阻止误用的方法包括建立新类型，限制类型上的操作，束缚类型值，以及消除客户的资源管理责任。
4、trl::shared_ptr 支持定制型删除器（custom deleter）。这可防范 DLL 问题，可被用来自动解除互斥锁（mutexes，见条款14）等等。