如何设计接口的参数以减少对接口的修改

 

 

 

在稍大型一点的项目中，总会有一个base层，我们认为它封装了最最底层和基础的一些列功能，因为底层的东西追求稳定和运行效率，所以90%是用C/C++写的，一般以头文件+DLL的方式给上层使用（不考虑它是基于COM的，如果是COM，VARIANT的参数类型就不在讨论范围内了）。头文件中定义了一些列导出函数或者导出类，这些导出函数或类的成员函数，都会有一些列参数，由于C/C++是强类型语言，所有强类型语言对类型转换都是极其严格的，不能像javascript里那样用var j = ... 的形式搞定一切。所以，底层接口中函数的参数如何设计是非常重要的。

 

假设有一个接口void A(int a)，就只能接受一个int类型作为参数。

 

1、当需求变了，需要处理string类型时，就要修改A或者增加新的接口A1；

 

     void A(int a);

 

     void A(const string& str);

 

或void A1(const string& str);

 

2、当参数个数变了，需要接受两个int时，仍然需要修改；

 

   void A(int a, int b);

 

   如果两天后上层又提需求，说需要三个int参数...好吧，再改

 

   void A(int a, int b, int c);

 

如果确实修改了这个接口A的参数类型或者参数个数或者增加新的接口A1，则必然导致至少两中问题：

 

1、所有引用这个头文件的cpp文件重编，而一个底层模块在整个项目中使用的普遍性是非常高的，那么最严重的情况就是，修改了一个头文件，造成整个项目重编；

 

2、所有调用过这个接口的上层代码都需要重新修改，更悲剧的是，还需要重新测试。

 

 

 

 

所以，如何才能涉及出具有很强适应力和扩展性的接口及参数类型，对于底层的接口是很重要的，也是必须的。

 

 

 

 

大概总结了一些，目测有这么几种方案，有些是坑爹的，有些在某些场合特定场合比较使用，有些比较通用。

 

1. void*

 

void*做参数在纯C语言写的代码里还是挺常见的，比如一个接口void A(void* p);

 

那如果你在A里对p进行某些类型转换，比如double *pd = (double*)p; 而传入的p原先是int* pn，那就惨了，多半*pd 不是原来的*pn，这就是用void*做参数的悲剧之处，它不携带原来的类型信息，对于使用者来说不知道应该怎么转，而且转了就有风险。这种void*参数现在几乎是绝对不允许使用的。

 

2.联合体类型

 

 

[html] 

struct param  

{  

      int id;  

      union BaseArg  

    {  

        struct CommonEventArg  

        {  

            RECT         rcItem;  

        }CommonEventArgs;  

        struct RightMenuArg  

        {  

            BOOL bShowDesk;  

            BOOL bWndMoved;  

            int  nIconSize;  

        }RightMenuArgs;  

        struct ItemDragArg  

        {  

            RECT rcBegin;  

            RECT rcEnd;  

        }ItemDragArgs;  

        struct ItemSelectArg  

        {  

            BOOL isSelected;  

        }ItemSelectArgs;  

        struct BoxItemUpdateArg  

        {  

            RECT rcBegin;  

        }BoxItemUpdateArgs;  

        struct BoxRenameArg  

        {  

            wchar_t *pszName;  

        }BoxRenameArgs;  

        struct FileChangeArg  

        {  

            LPITEMIDLIST  pItem;  

            LPITEMIDLIST  pAdditionItem;  

        }FileChangeArgs;  

        struct RightMenuResponseArg  

        {  

            int nX;  

            int nY;  

        }MenuResponse;  

        struct StringArg  

        {  

            const wchar_t *pszName;  

        }StringArgs;  

    }Data;  

};  

 

struct param

{

      int id;

      union BaseArg

    {

        struct CommonEventArg

        {

            RECT         rcItem;

        }CommonEventArgs;

        struct RightMenuArg

        {

            BOOL bShowDesk;

            BOOL bWndMoved;

            int  nIconSize;

        }RightMenuArgs;

        struct ItemDragArg

        {

            RECT rcBegin;

            RECT rcEnd;

        }ItemDragArgs;

        struct ItemSelectArg

        {

            BOOL isSelected;

        }ItemSelectArgs;

        struct BoxItemUpdateArg

        {

            RECT rcBegin;

        }BoxItemUpdateArgs;

        struct BoxRenameArg

        {

            wchar_t *pszName;

        }BoxRenameArgs;

        struct FileChangeArg

        {

            LPITEMIDLIST  pItem;

            LPITEMIDLIST  pAdditionItem;

        }FileChangeArgs;

        struct RightMenuResponseArg

        {

            int nX;

            int nY;

        }MenuResponse;

        struct StringArg

        {

            const wchar_t *pszName;

        }StringArgs;

    }Data;

};比如这样一个结构体参数param，它包了一个联合体，这样做的思路也很清晰，接口这么定义：void A(const param& p);当需要变时，就去改param里面的结构就好，外头不用动。里面增加了联合体的包装，其实是把这种思路优化了一把，因为如果param使用场合很多，用到N多种结构体，那么一个param对象就占用很多内存，而我们知道联合体并不会给它的每一个成员分配内存，而是用它内存需要最多的那个成员的内存长度作为整个联合体的内存长度，这样，就着实省了一把内存。 

 

这样的涉及，比较常见的应用场合貌似是消息的响应，似乎MFC里的消息响应就是这么涉及的，Mouse消息、LBtn消息等等各自有不同的子struct包在联合体内。

 

3.json做参数

 

json做为一种小巧轻便易解析，最重要的强大的可修改性和可扩展性（这点有上面第二点struct+union的意思，但更强大）的玩意，不做参数实在是有点可惜，貌似我知道的的比较早的使用在网络传输，以及客户端和web方通信上比较多，其实网络传输也可以看成是一次函数调用嘛，那json就可以理解成这个函数调用的参数了。

 

4.模版

 

模版生来就是为了泛化的，经典的 int Add(int a, int b)经过模版化后就可以处理所有数值类型的加法操作了，但问题是什么呢？问题就是模版函数或模板类不适合作为模块接口，如果是在模块内用模版那是完美的设计，但如果在模块接口一级用模版，那就悲催了。因为上面说了，模块一般是以头文件+DLL的方式提供，而模版的一个特点就是不支持分离编译（这个不清楚的自行google），就是说，模版的实例化是要在编译时才决定的，你把模版函数的声明和实现分别放在头文件和cpp中，那是不行滴，必须都放在头文件中，那这样也就不叫模块话了，直接全给头文件就行了，boost大部分是这么搞的。

 

5.boost::any

 

这个东西是boost提供的又一牛逼东西，实现了类似于var j = ...的傻瓜式参数类型，相当于把本身强类型的C/C++中的参数封装成javascript中的弱类型。

 

 

[html] 

void my_func(boost::any a)  

{  

    if(a.type() == typeid(int))  

    {  

        //int类型  

    }  

    else if(a.type() == typeid(string))  

    {  

        //string类型  

    }  

    //...  

}  

my_func(10);  

my_func("123");  

class custom  

{  

    int b;  

    double d;  

};  

custom cus;  

my_func(cus);  

 

void my_func(boost::any a)

{

    if(a.type() == typeid(int))

    {

        //int类型

    }

    else if(a.type() == typeid(string))

    {

        //string类型

    }

    //...

}

my_func(10);

my_func("123");

class custom

{

    int b;

    double d;

};

custom cus;

my_func(cus);[html] view plaincopyprint?<SPAN style="FONT-FAMILY: Arial, Helvetica, sans-serif">  

</SPAN>  

 

 

[html] 

<SPAN style="FONT-FAMILY: Arial, Helvetica, sans-serif">或</SPAN>  

 

或[html] view plaincopyprint?<SPAN style="FONT-FAMILY: Arial, Helvetica, sans-serif">  

</SPAN>  

 

 

[html] 

typedef std::list<boost::any> list_any;  

list_any.push_back(10);  

list_any.push_back("123");  

class custom  

{  

    int b;  

    double c;  

    char *p;  

};  

custom cus;  

list_any.push_back(cus);  

 

typedef std::list<boost::any> list_any;

list_any.push_back(10);

list_any.push_back("123");

class custom

{

    int b;

    double c;

    char *p;

};

custom cus;

list_any.push_back(cus);[html] view plaincopyprint?<SPAN style="FONT-FAMILY: Arial, Helvetica, sans-serif">  

</SPAN>  

 

 

[html] 

<SPAN style="FONT-FAMILY: Arial, Helvetica, sans-serif">一个python中的列表就诞生了。</SPAN>  

 

一个python中的列表就诞生了。[html] view plaincopyprint?<SPAN style="FONT-FAMILY: Arial, Helvetica, sans-serif">貌似设计模式里的开放封闭原则套到函数参数的设计上也是适用的吧，提高参数扩展性，尽量不修改。</SPAN>