设计模式之ArcGIS的API设计

      去年一年在外出差做项目实施有10个月。所做的工作都是ArcGIS的扩展研究及开发。

      今年终于有时间停下来，学习一下新的东西，认真总结一下自己的知识了。因为C++中没有反射机制，而且是ArcGIS是基于COM技术的，所以ArcGIS的扩展都是基于COM技术的。如何扩展其实就是做两件事，一，确定是否有扩展点，而，如果有扩展点，实现需要实现的接口，完成接口中的方法。

      扩展需要什么基础？其实做了很多之后就两点，一是不做假设，而是了解C++的常用设计模式。

      在组件式开发的基础上写扩展最重要的一个原则就是不做假设，你不能假设接口中的方法是在什么环境下返回特定的东西。而因该考虑通用的设计下，我只返回Client调用过程中需要的东西，此处对返回不能特化。这个地方的确很难理解。因为扩展的组件可以在任何环境下采用，如果特化，调用顺序或方式改变，就有可能发生问题。譬如，我为电信机站渲染写的ISymbol扩展组件，9.3下的ISymbol内的方法的调用顺序和9.2下ISymbol内的调用顺序是有差别的，假如我对接口内的方法调用顺序有假设(可能会利于GDI初始化)，结果就会出现问题。

      关于模式，我在ArcGIS的开发中不断的学习和总结。事实上ArcGIS的架构是相当精良的。有些人说是设计过度，那是因为他自己没有深入到扩展应用的层次，只是做些代码的堆积，如果仅是这样开发，这些人是不需要懂得设计和模式的；事实上大部分的GIS功能在ArcGIS的组件中已经提供，用户需要学习的仅仅是如何按照顺序去调用，至于组件是如何写出来的，大部分人是不会去关心和了解的。  

     对于ArcGIS模式的了解也是一个长期的过程，事实上通过ArcGIS自己提供的对象模型图(OMD)我们是可以了解一些产品架构的，但是仅限于此还是很难了解底层的架构。我觉得最有用的是研究ArcGIS提供的扩展例子和说明，在GOOGLE上搜索Extending ArcObjects可以找到许多相关例子。此外通过动手写一些组件，通过VC调试器查看AO的接口调用过程也能弄清楚具体调用细节。但是可以肯定地是清楚了解模式是所有这些的基础。

      ArcGIS的API中最长用的几种模式有factory,bridge,facde,等等。日后会慢慢总结自己所做的逆向工程。因为ArcGIS在以后的产品进化过程中会往轻量级应用靠近(便于云部署)，但是产品的设计框架会更强调架构上的灵活性。