C/C++编程：让接口容易被正确使用，不易被误用

ゝ一纸荒年。 2023-01-19 12:48 4阅读 0赞

# 细节 #

> C++中有很多接口：函数接口、类接口、模版接口…，客户通过接口使用你的代码。理想上，如果客户企图使用某个接口而却没有获得它预期的行为，这个代码不应该通过编译；如果代码通过了编译，它的作为就是客户想要的。

那什么设计一个好用的接口呢？

第一点，你必须考虑客户可能的错误。

看个例子：

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

这里，客户可能会传递一个错误的参数次序，或者传递一个无效的月份或者天数：

Date d(30, 3, 1995);
    Date d(2, 31, 1995);

这样的错误，可以**通过导入新类型而预防**。是的，**类型系统可以帮助防范"不值得拥有的代码"**。现在，我们来导入外置类型来区分天数，月份，年份：

struct Day{
        
    	explicit Day(int d) : val(d){
        }
    	int val;
    };
    
    struct Month{
        
    	explicit Month(int m) : val(m) {
        }
    	int val;
    };
    
    struct Year{
        
    	explicit 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);                   // error, 不正确的类型
    Date d(Day(30), Month(3), Year(1995)); // error, 不正确的类型
    Date d(Month(3), Day(30), Year(1995)); // ok, 类型正确

从上面就可以看出，导入新类型对预防接口被误用有奇效。当然，令Day， Month，Year称为成熟的class并封装其内数据，比简单的struct更好

一旦正确的类型被定位，限制其值有时候是有必要的。比如一年只有12个月，所以Month应该反映这一事实。方法之一是利用enum表现月份，另一种方法是预先定义所有有效的Months：

class Month{
        
    public:
    	static Month Jan() {
        return Month(1);};
    	static Month Feb() {
        return Month(2);};
    	...
    	static Month Dec() {
        return Month(12);};
    private:
    	explicit Month(int m); // 阻止生成新的月份
    };

预防客户错误的另一个方法是，限制类型内什么事可以做，什么事情不可以做。场景的显示是加上const。比如`以const修饰operator*的返回值类型可以阻止客户因用户自定义类型而犯错`

if(a * b = c)   // 原本是想比较

`除非有好理由，否则应该尽量令你的types的行为与内置types一致`。比如a和b都是int，那么对a\*b赋值并不合法，所以你的types也应该有相同的表现。是的，一旦怀疑，请拿int做范本。

`必须无端与内置类型不兼容`。

任何接口如何要求客户必须记得做某些事情，就是有着不正确使用的倾向，因为客户可能会忘记做那件事。比如下面：

Investment * createInvestment();

为了避免资源泄漏，createInvestment()返回的指针必须被删除。

但是客户很可能忘记删除这个资源，更好的方法是改进这个接口，令factory返回一个智能指针：

std::shared_ptr<Investment > createInvestment();

假如类的设计者期望那些"从 createInvestment();取得Investment\*指针"的客户将该指针传递给一个名为getPidofInvestment()的指针，而不是直接使用delete，那么接口就不能向上面这样写了。类的设计者可以针对此问题，返回一个"将getPidofInvestment()绑定为删除器"的shared\_ptr。

shared\_ptr提供的某个构造函数接受两个实参：一个是被管理的指针，另一个是引用次数变成0时将被调用的删除器。这启发我们创建一个null shared\_ptr并以getPidofInvestment作为其删除器：

std::shared_ptr<Investment> p(0, getPidofInvestment); // 企图创建一个null shared_ptr并携带一个自定删除器。无法通过编译

上面无法通过变异，因为shared\_ptr构造参数的第一个参数必须是个指针，而0不是指针，因此应该使用转型(cast)：

std::shared_ptr<Investment>p(static_cast<Investment*>(0), getPidofInvestment)  // 企图创建一个null shared_ptr并携带一个自定删除器getPidofInvestment。

也就是说，代码应该是这样：

std::shared_ptr<Investment > createInvestment(){
        
    	std::shared_ptr<Investment>p(static_cast<Investment*>(0), getPidofInvestment) ;
    	p = ... ; //令p指向正确对象
    	return p;
    }

shared\_ptr另一个好的性质是：它会自动使用它的"每个指针专属的删除器"，因而消除"cross-DLL problem"。这个问题发生于"对象在动态链接库dll中被new创建，却在另一个dll内被delete销毁"。这可能导致运行期错误，而shared\_ptr消除了这个错误，因为它缺省的删除器是来自"shared\_ptr"诞生所在的那个DLL的delete。

# 总结 #

*  好的接口接口应该容易被正确使用，不易被无用
 *  "促进正确使用"的办法包括接口的一致性、以及与内置类型兼容
    
     *  接口的一致性：比如所有的容器都有一个size()函数获得元素个数
 *  "阻止误用"的办法包括建立新类型、限制类型上的操作、束缚对象值、以及消除客户的资源管理责任
 *  shared\_ptr支持定制删除器。这可以用来防范DLL问题，可被用来自动解除自动删除互斥锁