設計模式之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在以後的產品進化過程中會往輕量級應用靠近(便於雲部署)，但是產品的設計架構會更強調架構上的靈活性。