1.接口设计的重要性
软件设计就是让软件做你想做的事，软件设计一定需要接口(interface)设计，最后用C++实现。今天讨论的可能是其中最重要的一条守则，把你的接口设计得容易用对，不容易用错。所谓的接口即你提供给用户使用你代码的途径。C++到处都充满了接口的概念，比如函数接口，类接口，模板接口。理想条件下，如果我们用错了接口，编译器会报错，而如果编译器没有报错，那么我们用的接口就是对的。
2.接口设计准则准则1
要把接口设计得好用对、难用错，就需要预先考虑到用户可能犯的各种错误。假如你正在设计一个表示日期的类:
1class Date{
2public:
3 Date(int month, int day, int year); // 美式标准表示年、月、日顺序
4};
第一眼看起来是没问题的，但用户可能会出现这样的错误。例如，有个英国人输入了错误的格式；有个美国人打错了字，输入了非法日期。
1Date d(30, 3, 1995); // 规定输入美式标准的月，日，年
2Date d(3, 40, 1995); // 把3打成了4
1// 3个包装类
2struct Day{
3 explicit Day(int d):val(d){}
4 int val;
5};
6
7struct Month{
8 explicit Month(int m): val(m){}
9 int val;
10};
11
12struct Year{
13 explicit Year(int y): val(y){}
14 int val;
15};
16
17// 下面开始使用
18class Date{
19public:
20 Date(const Month& m, const Day& d, const Year& y);
21 // ...
22};
23
24Date d(30, 3, 1995); // int类型不正确报错
25Date d(Day(30), Month(3), Year(1995)); // 格式错误报错
26Date d(Month(3), Day(30), Year(1995)); // 正确
上面接口中我们保证了格式的正确，下一步就是要对取值做出规范，例如月份只能有1到12。使用enum可以满足功能上的要求，但enum不是类型安全的(type safe)，因为在前面的文章尽量以const、enum、inline替换#define中已经展示过enum可以被用来当作int类型使用。因此，我们需要定义包含所有月份的集合。
1class Month{
2public:
3 static Month Jan(){ return Month(1);}
4 static Month Feb(){return Month(2);}
5 // ...
6 static Month Dec(){return Month(12);}
7 // ...
8private:
9 explicit Month(int m); // explicit禁止参数隐式转换，private禁止用户生成自定义的月份
10 // ...
11};
12
13Date d(Month::Feb(), Day(29), Year(2020)); // 正确
准则2
要把接口设计得具有一致性。C++STL容器接口相比其它语言可以说是达到了高度一致性，因此这些接口也相比更加易用，例如每一个STL容器类都有一个成员函数size()来返回容器当前包含的对象数量。
不像Java，对于数组要使用length属性；对于字符串要使用length方法；对于List要使用size方法，总之各种各样的接口。在.NET中，对于数组要使用Length属性，对于ArrayList又要使用Count属性。可能有些开发者会认为，使用了集成开发环境(IDE)，这些不一致性就显得不那么重要。但是，不一致的接口仍然会带来心理上的困难感，因为明显你需要记住更多东西，这是IDE不能弥补的。
接口设计具有一致性也有另外一层意思，是指行为上的一致性，就是要把功能做得与原始类型或是其它标准类型的逻辑一致。前面的文章尽可能使用const修饰符，展示了*运算符用const修饰返回值来避免因为打错字所带来的无意义赋值。
1if(a * b = c) // 应该是a * b == c
准则3
任何要求用户记住东西的接口都更容易造成误用，因为用户也不是电脑，只要是人类就会忘掉东西。例如动态分配了一个资源，要求用户以某种特定的方式释放资源。在前面的文章C++中基于对象来管理资源中，我们引入了一个工厂函数createInvestment()。
1Investment* createInvestment();
为了防止资源泄漏，这个动态分配的资源必须在使用完后删除，但要求用户这样做可能会产生两种情景:
a.用户忘记删除b.多次删除同一个指针 在前面的文章C++中基于对象来管理资源中解决方法是使用智能指针自动管理资源，但如果用户忘记把这个函数的返回值封装在智能指针内呢？所以，我们最好让这个函数直接返回一个智能指针对象:
1std::shared_ptr<Investment> createInvestment();
事实上，返回一个智能指针还解决了一系列用户端资源泄漏的问题。前面的文章C++当心资源管理类中的拷贝行为中提到，如果默认的删除器(deleter)不好用，我们可以给shared_ptr绑定一个自定义的删除器，从而来自动实现我们想要的析构功能。不仅仅是内存资源，通过绑定删除器，我们还可以管理更多种类的资源。例如，前面的文章C++当心资源管理类中的拷贝行为中提及的Mutex锁。
假设我们规定：如果用户从这个工厂函数得到了一个Investment*对象，在析构时要用另一个getRidOfInvestment()函数来释放资源，而不是单独使用delete。这就可能会导致用户由于忘记而使用了错误的释放机制。要防止这种错误，我们把getRidOfInvestment()绑定到shared_ptr的删除器，这样shared_ptr就会在使用完成后自动帮用户调用释放函数。
绑定删除器另一个好处是避免了DLL交叉问题(cross-DLL problem)。这个问题是发生在当一个对象从一个DLL(动态链接库)中生成，在另一个DLL中释放时，在许多平台上就会导致运行时的问题。这是由于不同DLL的new和delete可能会被链接到不同代码。但是，shared_ptr的删除器则是固定绑定在创建它的DLL中。例如，我们有Stock类继承自Investment:
1std::shared_ptr<Investment> createInvestment(){
2 return std::shared_ptr<Investment>(new Stock);
3}
