凭据范例名称动态建设工具

副标题#e#

1 引言

我的一个实际项目中，由于但愿通过一致的接口节制各范例号的设备，而且可以利便的随时扩充，以便未来支持更多的型号。因此，必需在运行时指定设备的型号。

为了使应用措施可以透明的节制各范例号的设备，所以成立了一个简朴的担任体系，设计一个协议类(Protocol Class)作为设备的节制接口，而且为每个型号的设备设计了一个详细的类，从协议类派生而且实现了抽象的民众接口。

因此，我需要一种手段，按照设备的型号在运行时动态的建设设备类实例。不然，假如在编译时硬编码(Hard Code)设备设置，将失去实用性和机动性。

最终的功效是，需要这样一种技能，可以实现

Motor* motor=ClassByName("IM9001");

雷同的成果。

2 设计和实现

现有的要害类的代码片段如下：

class IntelligentMotor
　 　　{
　 　　public:
　 　　　　IntelligentMotor(const std::string& port_name);
　 　　　　virtual bool Start()=0;
　 　　　　virtual bool Stop()=0;
　 　　　　virtual ~IntelligentMotor();
　 　　};
　　class IM9001　　:　　public IntelligentMotor
　 　　{
　 　　public:
　 　　　　IM9001(const std::string& port_name);
　 　　　　virtual bool Start();
　 　　　　virtual bool Stop();
　 　　　　virtual ~IM9001();
　 　　private:
　 　　　　// ...
　 　　};
　　class IM9002　　:　　public IntelligentMotor
　 　　{
　 　　public:
　 　　　　IM9002(const std::string& port_name);
　 　　　　virtual bool Start();
　 　　　　virtual bool Stop();
　 　　　　virtual ~IM9002();
　 　　private:
　 　　　　// ...
　 　　};
　　// more model ...

#p#副标题#e#

如何实现ClassByName呢？

我们虽然可以在ClassByName中利用一个多重分支查抄来实现，也就是

IntelligentMotor* ClassByName(const std::string& model_name,
　 　　　　const std::string& port_name)
　 　　{
　 　　　　if (model_name=="IM9001")
　 　　　　　　return new IM9001(port_name);
　 　　　　else if (model_name=="IM9002")
　 　　　　　　return new IM9002(port_name);
　 　　　　// 所有支持的型号
　 　　　　else
　 　　　　　　throw "不支持该型号的设备。";
　 　　}

然而这种编程气势气魄是糟糕的。跟着系统支持的型号种类增加，分支查抄语句的长度也会同时增加，造成代码尺寸膨胀和可维护性的下降。

因此必需在范例名字和类(可能类的实例)之间成立一种映射。由于派生类的指针(或引用)可以隐式的转换成基类的指针(或引用)，因此很容易获得这样的结构：

struct Map
　　　{
　　　　　const std::string ModelName;
　　　　　IntelligentMotor* Device;
　　　};

进而我们还可以结构一个型号映射表，而且在编译时增加所有支持的型号。

Map ModelTable[]=
　　　{
　　　　　{"IM9001",new IM9001},
　　　　　{"IM9002",new IM9002}
　　　　　// 所有支持的型号
　　　};

然后就获得了更清晰的ClassByName。

IntelligentMotot* ClassByName(const std::string& model_name,
　　　　　const std::string& port_name)
　　　{
　　　　　for (int i=0;i<sizeof(ModelTable)/sizeof(Map);++i)
　　　　　{
　　　　　　　if (model_name==ModelTable[i].ModelName)
　　　　　　　　　return ModelTable[i].Device;
　　　　　}
　　　　　throw "不支持该型号的设备。";
　　　}

#p#副标题#e#

然而，在上面我存心忽略了一个问题，设备类(IM9001, IM9002等)并没有提供默认结构函数，因此实际上这些代码是无法通过编译的。可以通过修改接口的设计来避开这个问题，即增加默认结构函数和指定端口的结构函数。固然这和实际环境不符(因为这里的设备不支持热插拔，不能再措施运行时改换毗连的端口)，可是为了便于实现也是可以接管的。

可是，更隐蔽的一个缺陷是，假如设备类自己的尺寸较大，那么为所有支持的型号建设实例，将增加空间负荷，而实际上实际利用的设备大概仅仅只用到个中的两三个型号罢了。

从这个角度看，型号映射表中应该映射的是类的建设器，而不是类的实例自己，而类的建设器险些没有什么空间承担。

这里有一个极其简朴的建设器，

#p#分页标题#e#

template <class T>
　　　IntelligentMotor* IntelligentMotorCreator(const std::string& port_name)
　　　{
　　　　　return new T(port_name);
　　　}

此刻我们的映射表酿成了

typedef IntelligentMotor* (*Creator)(const std::string& port_name);
　　　struct Map
　　　{
　　　　　const std::string ModelName;
　　　　　Creator DeviceCreator;
　　　};
　　　Map model_table[]=
　　　{
　　　　　{"IM9001",&(IntelligentMotorCreator<IM9001>)},
　　　　　{"IM9002",&(IntelligentMotorCreator<IM9002>)}
　　　　　//...
　　　};

而ClassByName则酿成了

IntelligentMotor* ClassByName(const std::string& model_name,
　 　　　　const std::string& port_name)
　 　　{
　 　　　　for (int i=0;i<sizeof(model_table)/sizeof(Map);++i)
　 　　　　{
　 　　　　　　if (model_name==model_table[i].ModelName)
　 　　　　　　　　return (*model_table[i].DeviceCreator)
　 　　　　　　　　　　(port_name);
　 　　　　}
　 　　　　throw "不支持该型号的设备。";
　 　　}

#p#副标题#e#

3 扩充

我们此刻有了实用的ClassByName，可是尚有几个小问题等候我们去办理。

首先，假如查找成为一种费时的操纵，那么我们可以利用一个关联数组取代内建数组提供范例查找成果。也就是

typedef std::map<std::string,Creator> ClassLookupTable;
　 　　ClassLookupTable model_lookup_table;
　 　　for (int i=0;i<sizeof(ModelTable)/sizeof(Map);++i)
　 　　　　model_lookup_table[ModelTable[i].ModelName] 　 　　　　　　=ModelTable[i].DeviceCreator;

这时我们的最新版的ClassByName则拥有了略低的平均巨大度。

IntelligentMotor* ClassByName(const std::string& model_name,
　 　　　　const std::string& port_name)
　 　　{
　 　　　　ClassLookupTable::const_iterator pos;
　 　　　　pos=model_lookup_table.find(model_name);
　 　　　　if (pos==model_lookup_table.end())
　 　　　　　　throw "不支持该型号的设备。";
　 　　　　return (*pos->second)(port_name);
　 　　}

不外这里有一个设计上的决定需要利用者作出，因为这个版本需要更多的时间和空间成立快速查找表，这是一种“一次支付，多次分期摊还本钱”的优化计策，必需按照实际环境抉择。

其次，为了减低编译依赖性，可以将所有的代码封装成库(可能是共享库，如动态链接库DLL)，只输出一个ClassByName接口，并单独提供协议类IntelligentMotor的接口，这样只要不改变协议类的接口，那么利用ClassByName的代码不需要因为增加新型号的设备而从头编译，假如是共享库的形式，那么甚至从头链接都不需要，只需要从头编译独立的设备型号库即可。

无论如何，照旧必需手工的为支持每一个新的型号而需要手工修改范例建设器的表格。我实在无法利用模板来处理惩罚这种异常离奇的环境，不管是内建数组，照旧尺度容器，都无法处理惩罚异种范例殽杂的元素，只能利用基类指针可能所谓的泛型指针(void *)，从范例安详性来说，向上转型(up-cast)的基类指针更为符合。这就隐含了一个限制，假如是一个任意范例的范例库系统，则必需要求成立严格的单根集成体系，然而据我所知，不管是Java照旧VCL，都同样对此做出了限制，MFC好像利用了宏，可是我不确定是否降服了这个挑战。

更一般化的动态建设工具技能，可以阅读Andrei Alexandrescu的<<Modern C++ Design>>一书，个中第八章Object Factory先容了完整的动态建设工具的要领。从根基道理上来说，个中利用的技能和本文中的相雷同，然而此书中的实现越发机动、高效和通用。

4 应用

正如前面提起过的，本文先容的技能，可以用于按照范例名称动态的建设该范例的实例。

典范的，这种动态建设类实例的要领，是结构可存储的工具库(IO object libaray)的常用要领，但愿在本身开拓的应用框架中提供工具耐久性(Persistance)的用户，可以参考本文的技能。