記得十多年前我剛畢業的第一份工作就是負責電力SCADA的人機界面互動子產品，當時大部分電力行業都是采用VC/MFC或QT來實作界面呈現，其實至今也依然如此，前端時間和老朋友聚會了解到他們還在用VC6編譯系統，如今的VS20**根本跑不動他們龐大的古老系統，當然也許他們沒配置好工具參數，但從一個側面你可以感受到老系統遷移之重，大部分程式員處于為項目業務功能疲于奔命狀态，上百号人這麼多年在根本無力優化和重構的架子上不斷堆積功能，我記得當時一個mousedown函數居然堆了六千多行代碼，各種圖元類型的draw代碼也是長得不堪入目，這些老系統雖然不好維護但也考這麼多程式員活生生的維護下來了，我們每天能正常的用水用電用氣，背後都是靠着衆多程式員的血汗維護着以如今眼光看完全不堪入目的爛代碼，不得不承認在中國能用是第一位，其他問題隻要堆人能解決的都不是問題。有點扯遠了，上幾張我以前電力實作的圖庫工具：
實作功能并不難，當時也實作了組合和分解圖元，能進行圖庫管理和使用者自定義，我相信全世界肯定不下幾百上千套繪圖軟體，剛開始我還是很興奮，每天學習不同的繪制API，就能搗鼓出新效果，我也不在乎代碼架構，每天就是以學習掌握更多的龐大MFC庫為榮，但當你掌握大部分繪圖技巧後，我發現自己每天維護這種龐大到無法以個人力量進行大規模重構，又不得不持續維護每天堆積功能性體力活代碼時，我感覺自己在浪費生命，于是跳槽到了另外一家公司打算做電子商務，結果陰差陽錯又被安排到電力部門幹起來繪圖工具，還好這次我能換個新語言Java，沒有曆史包袱完全自己重頭設計圖形架構，于是地球上出現了第1001個繪圖工具：
這一版設計上還是有很大的改進，圖形繪制邏輯，互動代碼以及界面布局等都進行了較合理的分工設計，那個Java和設計模式很火，人手一本Martin Fowler《Refactoring: Improving the Design of Existing Code》，猶如宗教信仰堅決執行一個函數不超過幾十行的時代，一個mousedown幾千行的代碼已經絕迹了，但我還是很不滿意，資料模型和界面繪制沒有很好的有機結合機制，雖然電力要求界面有***的毫秒級響應，但大部分公司都是像遊戲重新整理機制那樣不斷repaint界面，是的，當時的資料模型沒有任何事件派發機制，就是記憶體中的一堆資料，你無法知道哪個資料什麼時候change了，因而隻能不斷的repaint界面，重新整理周期太短對于大的網絡拓撲圖根本來不及更新，更新周期太長又達不到響應要求，至于所謂的***毫秒級響應我隻能呵呵了，為了上這個系統一堆兄弟在沈陽某農村封閉了八個多月，我很好奇那個老系統現在是否健在…
以上是在矢量編輯器中打開的效果圖，你可以清晰的看得到我們定義的幾個元素的位置大小示範等，這樣應用時隻要建構一個Node對象，将其image設定為switch矢量，那麼将來隻需要調用node.setStyle(‘switch.angle’, Math.PI/6)就可以随時随地控制刀閘展開角度 。
這樣封裝還不夠完美，對應用着來說他們隻關心刀閘的打開和關閉的操作，他們并不關心旋轉角度，開和關是業務角度的了解，而旋轉角度是底層實作圖形上的參數，并且使用者還需要開關過程有動畫效果，于是我們進行了進一步的封裝，設計了ht.Switch的類，提供了setExpanded的函數，在函數裡面操作底層綁定圖形的‘switch.angle’屬性，以及啟動動畫封裝：
最後幾點設計控件的建議：
切換到使用者角度，即站在上層應用者角度提供最簡潔符合業務邏輯的API接口，盡量不暴露圖形相關參數，圖形參數對上層使用着是晦澀的，暴露了你自己也是非常難改動和維護
不要一開始設計就考慮如何操作，如何動畫，操作和動畫都可以在基礎API基礎上擴充再封裝，某種程度上來說，如何操作和如何動畫甚至不屬于控件封裝該幹的，至少可再提供進一層的封裝，這樣可随意切換操作和動畫邏輯，而不影響底層控件的資料模型和繪制邏輯
盡量讓繪制代碼和業務邏輯代碼分離，這點如果采用最基礎的繪制代碼的确很難分離，這也是HT盡量采用矢量描述，不讓使用者控制底層繪制代碼的初衷