去年一年在外出差做專案實施有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在以後的產品進化過程中會往輕量級應用靠近(便於雲部署)，但是產品的設計框架會更強調架構上的靈活性。
服務API設計 之 API設計原則
對接xx業務時，xx業務具備的功能和api全靠跑業務負責人那反覆逐個詢問 確認。用哪個api 怎麼用 有沒有限制 等等 各個業務間，甚至同一業務內，api風格不統一。xx業務api效能方面未知。隨著業務的演進，開放的api持續在增加，但類同的很多 api編碼規範迫在眉睫 自解釋 易學習 易使用 難誤...
服務API設計 之 API版本規範
正式發布的api包必須是release版本 eg.cn.gov.zcy.paas.template template api 2.1.1.release 使用 semantic versioning 風格 version號由 major.minor.patch 三段組合構成，version號增加含義...
設計模式之禪之設計模式 門面模式
1 package com.yeepay.sxf.template18 2 3 寫信的業務類 4 隱藏在門面角色裡邊，不需要暴露太多5 author sxf6 7 8public inte ce iletterprocess view code 寫信的業務類的實現 1 package com.yee...