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