本文不打算嚴格地、用標準術語來講前因后果。本文主要分析實踐中常見的、因為對原理不清楚而搞出來的產品里的坑。

什么是插件模式和為什么要用插件模式

插件，Plug-In，或者（IE/Edge稱之為）加載項/Add-On，（Office稱之為）外接程序/Add-In，（GIMP稱之為）擴展/Extension，等等，總之看字面意思都是“額外增加功能”的這種東西，是一類開發模式。基本思路就是，研發軟件本體的時候，外部需求不明確、直到使用期仍然經常會增加功能細節。為了把變動部分切割開，在設計的時候，通過對可變部分的歸納分析，對可變部分抽象出一套接口；每套外部需求用動態庫之類的形式實現接口；軟件本體按某種約定，加載動態庫，并從中獲取插件實例，通過接口來調用滿足當時需求的功能實現。

可以看到，插件的思想，其實就是靈活運用“動態庫”的動態加載能力，把對“接口”的實現移到軟件本體之外，并用工廠模式來約束動態庫的實現方式。

只要是具有動態加載能力的運行環境上，都可以使用插件模式來設計軟件系統。極端一些的軟件系統，甚至只提供基礎平臺，所有功能都由插件的方式提供，例如 Visual Studio Code 、 Eclipse 等。

C++實現插件模式

用C++實現插件模式，一般是把下面這些功能組合起來：

• 用一個C++的帶虛函數的基類來表示功能
• 約定動態庫里的工廠模式接口
• 在一些動態庫里提供實現虛函數的派生類
• 在動態庫里實現工廠模式

不幸的是，由于各操作系統的動態庫機制普遍是C風格的，用C++做動態庫時候的坑，在用C++實現插件模式時，全都會遇到。比如：

• C++的編譯器差異導致的不互通
  會導致必須用同一種（或兼容的）編譯器來生成插件和軟件本體。
  • 名字改寫（Name Mangling）：參考：Wikipedia、C/C++中的名字空間與作用域示例詳解?會導致加載插件時“找不到符號”
  • 虛函數（表）實現：
    會導致加載插件時可能不報錯，但運行時候找不到正確的虛函數入口
• 操作系統機制導致的不互通
  • Windows上使用MSVCRT時的內存分配和回收
    Windows每個模塊的內存分配默認是在模塊自己的堆里的，而Windows上的C運行時庫（各種MSVCRT）為了封裝出?malloc?、?free?等C函數的效果，建立了__crtheap（2010及之前版本行為）或直接使用進程默認堆（2015及之后版本行為）[1]。這導致，即使是同一個編譯器，靜態鏈接VC運行時會采用本模塊內部的堆來實現?malloc?等，而動態鏈接VC運行時則會采用MSVCRT動態庫DLL的模塊堆。需要解決好“誰申請誰釋放”的問題，否則內存管理的地方容易出異常。
  • 全局變量在模塊間的共享問題

一些典型的不良實現

這里說的不良實現，使用時候未必會錯或崩，但早晚要崩，或者會限制住插件的開發。以下用如下插件接口作為例子。

// IFilter.h
 
/// 濾波器接口.
class IFilter {
protected:
    IFilter();
public:
    virtual ~IFilter();
public:
    /// 一個將輸入復數數組處理為輸出復數數組的函數.
    virtual void Filter(const std::complex<double>* acdIn, std::complex<double>* acdOut, size_t uLen) = 0;
    /// 獲取當前實現的一些描述字符串.
    virtual std::string GetDescription() const = 0;
};
// IFilter.cpp
IFilter::IFilter() { }
IFilter::~IFilter() { }

并約定插件實現中以如下形式提供工廠函數。

// FilterPluginDll.h
#include "IFilter.h"
/* 插件DLL應該提供如下函數 
extern "C" int GetFilterPluginInDll(char* szFilterNamesBuf, size_t uBufLen);
extern "C" IFilter* BuildFilterPlugin(const char* szFilterName);
extern "C" void FreeFilterPlugin(IFilter* pFilter);
*/
typedef int (*PFNGetFilterPluginInDll)(char* szFilterNamesBuf, size_t uBufLen);
typedef IFilter* (*PFNBuildFilterPlugin)(const char* szFilterName);
typedef void (*PFNFreeFilterPlugin)(IFilter* pFilter);

接口類沒有提供二進制實現

比如，對插件只發布兩個頭文件；認為?IFilter?的構造和析構反正是空函數無所謂，直接寫在類定義里。

這樣，插件開發者自己生成插件DLL時，會在自己的DLL里鏈接進一份?IFilter::IFilter()?和?IFilter::~IFilter()?的實現，而軟件本體里也有一份自己的實現。雖然看上去，如果編譯器一樣，兩份實現是等同的，但考慮到它們使用了不同的模塊堆，以及其它各種原因，插件DLL中的?IFilter?和軟件本體里的?IFilter?并不是完全等同的。

這里應該由軟件本體導出?IFilter::IFitler()?和?IFilter::~IFilter()?等接口類的共性成分的實現給插件，以免出現一些奇怪的問題。

工廠函數里沒有正確設計“誰分配誰釋放”

比如，為了“簡單”，只要求了?BuildFilterPlugin?工廠函數，認為可以由軟件本體用?delete pFilter;?來釋放插件實例。

一種建議的實現方法

用類似于Windows的COM風格的“放了一堆函數指針的結構體”來表示插件的接口定義；軟件本體里為了使用方便，再用接口類包裝一下。

參考文獻

• 一個程序員的修煉之路. 談一談Windows中的堆 [EB/OL].?https://blog.csdn.net/CJF_iceKing/article/details/119083770