接口设计的总结

最新推荐文章于 2022-05-11 12:40:53 发布

sboom

最新推荐文章于 2022-05-11 12:40:53 发布

阅读量1k

点赞数

分类专栏：设计文章标签： attributes security api 语言 object xml

本文链接：https://blog.csdn.net/sboom/article/details/5593592

版权

设计专栏收录该内容

1 篇文章 0 订阅

订阅专栏

模块化与接口设计

在软件变得越来越庞大的时候，人们开始探索模块化编程，允许软件的某一部分功能封装成一个模块，在软件运行时由操作系统在磁盘上找寻对应的模块并加载使用，从此软件可以划分为相互独立的模块，允许不修改软件整体结构，仅单独更新某个模块而增强某个功能。

动态链接库 (DLL) 是一种很好的模块化技术，在软件运行时，动态链接库会被操作系统装载，并与主体程序链接，主体程序通过调用动态链接库中的函数实现某一个功能。在升级模块时主体程序不更新，因此动态链接库中的函数在更新时必须保持与主体程序的接口不变，否则主体程序调用动态链接库时将因为接口不匹配而出错。

教科书和开发经验都告诉我们，接口的设计要保持一定的稳定性，尽量减少接口变化带来的维护工作量。

C语言的做法

Windows 系统 API 显然有很强烈的接口不变性需求，因为 MS 也希望在他的操作系统升级后，旧版系统下的软件无须太大的改动就可以应用在新操作系统中。

WINDOWS API 是 C 语言接口， C 语言的一种常见做法是对参数结构体定义一个 length 字段，程序中通过判断 length 字段来区分不同版本的数据结构，这样就可以做到高版本的接口兼容低版本的接口

以 WINDOWS API 中启动进程的函数为例

BOOL WINAPI CreateProcess(

  __in_opt     LPCTSTR lpApplicationName,

  __inout_opt  LPTSTR lpCommandLine,

  __in_opt     LPSECURITY_ATTRIBUTES lpProcessAttributes,

  __in_opt     LPSECURITY_ATTRIBUTES lpThreadAttributes,

  __in         BOOL bInheritHandles,

  __in         DWORD dwCreationFlags,

  __in_opt     LPVOID lpEnvironment,

  __in_opt     LPCTSTR lpCurrentDirectory,

  __in         LPSTARTUPINFO lpStartupInfo,

  __out        LPPROCESS_INFORMATION lpProcessInformation

);

其中的参数 lpProcessAttributes 是 SECURITY_ATTRIBUTES 接口，定义如下

typedef struct _SECURITY_ATTRIBUTES {

  DWORD  nLength;

  LPVOID lpSecurityDescriptor;

  BOOL   bInheritHandle;

} SECURITY_ATTRIBUTES, *PSECURITY_ATTRIBUTES, *LPSECURITY_ATTRIBUTES;

可以看到 SECURITY_ATTRIBUTES 中的成员 nLength ，他描述的是 SECURITY_ATTRIBUTES 结构的大小，文档要求调用者指定传入的 SECURITY_ATTRIBUTES 参数的大小，一般的做法是取 sizeof(SECURITY_ATTRIBUTES) ，可以推断 API 的实现中将这样区分 lpSecurityDescriptor 参数的版本

if(sizeof(*lpSecurityDescriptor) == sizeof(SECURITY_ATTRIBUTES_NEWVERSION)){

//new implementation of this API...

}else if(sizeof(*lpSecurityDescriptor) == sizeof(SECURITY_ATTRIBUTES_OLDVERSION)){

//support old version of this API...

}

这样升级 API 时，接口定义不需要改动，当旧软件放到新版本的操作系统中运行时，新版本的 API 可以继续支持旧版本的调用程序，而在新操作系统下开发的新软件又可以使用新版本API 的特性，实现了接口不变的功能增强。

只是有一个小负担，就是多出了一个无业务意义，仅仅用来保持接口不变而设置的 nLength 成员，而且要求调用者编程时必须传入 sizeof(SECURITY_ATTRIBUTES) 的值，但它确实达到了目的。

这种接口在 WINDOWS API 中不为少数，在 UNIX 的库中似乎相对少一点，但也存在，比如 socket API

COM的做法

在 C++ 世界， COM 选择了一种更为花哨的做法，通过接口包容来实现

定义一个接口

virtual class IMyInterface1{

virtual void doSomething() = 0;

};

编写对象实现这个接口

class MyObject1 : public IMyInterface1{

virtual void doSomething();

};

通过 createInstance 创建 MyObject1 的对象并返回 IMyInterface1 ，调用端通过 IMyInterface1 来使用功能。当接口升级时，定义一个扩展接口

virtual class IMyInterface2 : public IMyInterface1{

virtual void doOtherthing() = 0;

};

新接口支持 2 个功能 doSomething 和 doOtherthing ，所以必须编写一个新类去实现新功能 doOtherthing ，并且希望旧功能 doSomething 的代码可以继续重用，新对象可以这么写

class MyObject2 : public ImyInterface2{

virtual void doSomething() ｛ obj1.doSomething();}

virtual void doOtherthing();

MyObject1 m_obj1;

};

当请求新对象的旧接口时转到旧对象中去实现，当请求新对象的新接口时使用新实现，新版本的 createInstance 根据新旧对象的 GUID 创建新对象或者旧对象，返回新接口指针或者旧接口指针，旧的调用者同样不需要作任何改变即可使用新的组件，而在新组件环境中编写的新调用端又可以使用新接口，它用样达到了接口不变的目的。

相比 C 语言的做法，少了用于支持接口设计的冗余字段 nLength ，但程序接口比 C 语言复杂了不少。

实际上 COM 的包容方案比上述稍微复杂一点点。另外 COM 还有另一个更复杂的方案－聚合，但聚合要求被聚合对象有附加的特殊设计，基本上被限定在 COM 的框架内，无法在一般 C++ 程序设计中通用，这里不讨论。