優化解耦的設計思考
基于開源項目進行開發已經越來越普遍，WebKit和Android都有很多的深度定制的版本。
對這樣龐大工程修改的邏輯越來越多，日后想要同步升級就要面對更大的復雜性和風險。跟隨開源項目同步升級，尋求上層的創新和優化才比較適合未來的產品開發策略。深度定制的方式會遭遇越來越多的尷尬。
修改是必要的，但如何最大化地降低耦合和隔離對原生代碼邏輯的修改？邏輯碎片的風險也許大家都體會過。以下是我對一個問題的思考，與大家分享，拋磚引玉。
1. 問題定義
首先交待一下當前的狀況。
1.有對WebKit原生內核中HTMLMediaElement修改的需求。
由于實現的限制，導致了必須對HTMLMediaElement進行修改。
2. 不同平臺的修改邏輯混雜在一起。
在不同平臺上的適配內容也不盡相同，所以其中有許多使用宏來區分系統的修改。
問題就是有沒有可能將這些修改的實現放到獨立的文件中去，在HTMLMediaElement中只做少量的修改，最大化的減少對原生代碼的修改？或者是有規則的修改?？傊阌诤妥钚碌腤ebKit代碼同步。
2. 問題分析
首先從設計上來看這個問題，可以將WebKit的實現視為核心邏輯，將我們的修改視為一個輔助邏輯或特殊邏輯。
這樣就可以有一個設計上問題定義:把這部分邏輯從主邏輯中抽離的設計方法，但不改變原來的類的層次架構。
繼承并不合適。因為一部分HTMLMediaElement中的成員定義為protected，它本身已經被HTMLAudioElement和HTMLVideoElement所繼承。還有對應的Render、JS Binding與它的對應問題。遠不是在parser位置將video和audio對應的類改成新類就可以的, 而是需要更改到HTMLMediaElement的定義。
解決方案就是提供一個Helper類，如MediaElementHelper來處理特殊邏輯。
2. 實現說明
2.1 建構
在HTMLMediaElement的建構函數中加入:
m_helper = MediaElementHelper::create(this);
不同平臺可以使用相同的類定義，但實現不同。
2.2 相互調用
helper又為HTMLMediaElement的友類,就可以訪問HTMLMediaElement的私有變量，或者執行私有成員函數。如果認為這樣風險高，也可以像下面這樣專為helper增加一些訪問私有成員的接口。
這樣在需要進行特殊邏輯判斷和處理的地方，就使用m_helper來調用執行。具體的行為則在不同的helper類中實現。
3. 評估
關于helper的使用一直是有爭議，網上也有很多避免使用helperclass的討論。主要論調在于認為helper class是過程化的產物，思考時是考慮的是流程上的邏輯補充。雖然在目前場景下，這也算是一個解決方案，但不是最佳方案，因為這些做同樣增加了設計的復雜性。
