按照类型名称动态创建对象

木子

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 ...
如何实现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 "不支持该型号的设备。";
   }
然而，在上面我故意忽略了一个问题，设备类(IM9001, IM9002等)并没有提供默认构造函数，因此实际上这些代码是无法通过编译的。可以通过修改接口的设计来避开这个问题，即增加默认构造函数和指定端口的构造函数。虽然这和实际情况不符(因为这里的设备不支持热插拔，不能再程序运行时更换连接的端口)，但是为了便于实现也是可以接受的。
但是，更隐蔽的一个缺陷是，如果设备类本身的尺寸较大，那么为所有支持的型号创建实例，将增加空间负荷，而实际上实际使用的设备可能仅仅只用到其中的两三个型号而已。
从这个角度看，型号映射表中应该映射的是类的创建器，而不是类的实例本身，而类的创建器几乎没有什么空间负担。
这里有一个极其简单的创建器，
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 "不支持该型号的设备。";
    }
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)的用户，可以参考本文的技术。

sunnygirl

有时候，不是对方不在乎你，而是你把对方看的太重。