框架往往是這樣產(chǎn)生的：我們擁有了開(kāi)發(fā)某種類(lèi)型應(yīng)用的大量經(jīng)驗(yàn)，并開(kāi)發(fā)了一些這種類(lèi)型的應(yīng)用，我們總結(jié)這種類(lèi)型的應(yīng)用中共性的東西，將其提煉到一個(gè)高的層次中，以備復(fù)用。這個(gè)“高的層次”的東西便是框架的原型。隨著我們經(jīng)驗(yàn)的不斷積累，框架也會(huì)不斷的向前完善、發(fā)展。框架，正如其名，就是一個(gè)應(yīng)用的骨架，選用的框架的好壞直接決定了基于其上構(gòu)建的應(yīng)用的質(zhì)量。在確定了一個(gè)框架后，我們?cè)诠羌艿目p隙里為其添加“血”和“肉”，便成為一個(gè)應(yīng)用。
　　框架源于應(yīng)用，卻又高于應(yīng)用。
　　我今天要說(shuō)的是，正是因?yàn)榭蚣茉从趹?yīng)用，所以在提煉框架的時(shí)候，我們往往不自覺(jué)的為框架作過(guò)多的假設(shè)。這些假設(shè)來(lái)源于孵化框架的具體應(yīng)用中的一些潛在的“規(guī)則”或約束。為什么了？因?yàn)槲覀兂３ＯＭ?#xff0c;使用了框架之后，這個(gè)孵化了框架的應(yīng)用再基于這個(gè)框架來(lái)重新構(gòu)建應(yīng)該非常簡(jiǎn)單。這種簡(jiǎn)單性會(huì)在兩種情況下出現(xiàn)：一是你成功地抽象出了一個(gè)非常好的框架；二是你抽象出的框架與孵化框架的應(yīng)用緊密的耦合在一起。如果沒(méi)有設(shè)計(jì)框架的經(jīng)驗(yàn)，我們陷入第二種情況是必然的。
　　框架與孵化框架的應(yīng)用的緊密耦合，換句話說(shuō)，就是為框架作過(guò)多的針對(duì)這個(gè)具體應(yīng)用的假設(shè)。在這種有過(guò)多假設(shè)的環(huán)境下設(shè)計(jì)框架導(dǎo)致的最直接的后果是：降低了框架的可復(fù)用性。我們提煉框架的目的是為了使之能在各個(gè)類(lèi)似的應(yīng)用中很好的復(fù)用，而依賴于太多的假設(shè)來(lái)設(shè)計(jì)框架將大大降低這一美好的目標(biāo)。
　　框架為應(yīng)用作過(guò)多的假設(shè)的一個(gè)非常具體的現(xiàn)象就是，框架越俎代庖，把本來(lái)是應(yīng)用要做的事情攬過(guò)來(lái)自己做。這是一種典型的吃力不討好的做法。框架越俎代庖，也許會(huì)使得一個(gè)應(yīng)用的開(kāi)發(fā)變得簡(jiǎn)單，卻會(huì)給其它更多想使用該框架的應(yīng)用增加了本沒(méi)有必要的束縛和負(fù)擔(dān)。
　　框架只做該做的事情，而哪些事情是該做的，取決于設(shè)計(jì)者的判斷，而判斷的正確與否取決于設(shè)計(jì)者的經(jīng)驗(yàn)和能力。
　　我們?cè)O(shè)計(jì)框架時(shí)，往往在框架中提供了很多內(nèi)置的組件，但是，框架不應(yīng)該強(qiáng)迫應(yīng)用使用任何一個(gè)最要、核心的組件。相反，框架應(yīng)該允許應(yīng)用提供組件的自定義實(shí)現(xiàn)來(lái)替換掉內(nèi)置的組件。這個(gè)可以通過(guò)組件的接口設(shè)計(jì)并暴露之而非常容易的做到。比如，我們的框架可以規(guī)定消息頭MessageHeader中必須包括哪些字段，但框架不能強(qiáng)制說(shuō)MessageHeader就只能包括這些字段。這個(gè)區(qū)別正是接口與實(shí)現(xiàn)(類(lèi))的區(qū)別。框架提供的是一系列的接口和這些接口之間的相互聯(lián)系，以構(gòu)成骨架；應(yīng)用實(shí)現(xiàn)這些接口以形成“血”和“肉”來(lái)填充這個(gè)骨架從而得到一個(gè)“有機(jī)體”。
　　空談了這么多，舉兩個(gè)例子吧，這兩個(gè)例子都是關(guān)于ESwork的。
　　第一個(gè)例子是，有段時(shí)間將ESwork定位為一個(gè)應(yīng)用框架，期望其能適用于所有的C/S應(yīng)用，于是，在ESwork中包含了大把與應(yīng)用相關(guān)的東西，使得ESwork越來(lái)越復(fù)雜和龐大。正如，能治百病的藥治不了任何病一樣，能滿足于所有應(yīng)用的框架幾乎不會(huì)被任何一個(gè)應(yīng)用采用。對(duì)這個(gè)錯(cuò)誤的解決方案的改成是，將ESwork定位于一個(gè)單純的通信框架，這會(huì)大大拓寬它的復(fù)用范圍。(更詳細(xì)描述可以參見(jiàn) ESwork 最新進(jìn)展 －－ ESwork體系)
　　第二個(gè)例子是，在早期版本的ESwork中有個(gè)名為ServiceType的枚舉，它將所有的消息進(jìn)行了分類(lèi)，說(shuō)實(shí)話，這種分類(lèi)非常適合IM系統(tǒng)，但對(duì)其它C/S系統(tǒng)并不一定合適。而且ESwork還針對(duì)這個(gè)ServiceType分類(lèi)提供了對(duì)應(yīng)的內(nèi)置的消息處理器(詳細(xì)情況)。現(xiàn)在看起來(lái)，這種做法是多么的笨！在后期的ESwork版本中，ESwork對(duì)消息如何分類(lèi)再?zèng)]有任何干涉，那些本不應(yīng)該存在的消息處理器也刪除了。取而代之的是使用一個(gè)DataDealerBagList，應(yīng)用可以向其中添加任何消息處理器，只要應(yīng)用將消息處理器與消息類(lèi)型進(jìn)行了正確的匹配就可以。
　　兩個(gè)例子說(shuō)完了，最后總結(jié)一下，我們的第一個(gè)經(jīng)驗(yàn)是：不要為框架作“過(guò)多”的假設(shè)，而不是：不要為框架作“任何”假設(shè)。一個(gè)沒(méi)有任何假設(shè)的框架，從另一個(gè)方向看，就是一個(gè)萬(wàn)能的、能解決任何問(wèn)題的框架，我們知道，這樣的框架是不存在的，即使存在，也是毫無(wú)用處的。
　　不要為框架作“過(guò)多”的假設(shè)，那么何謂“過(guò)多”了？有很多特性/組件，我們可以一眼就分辨出，它是應(yīng)該存在于框架中，還是應(yīng)該交給應(yīng)用。但是，也有一些特性/組件，它們的所宿地就不是那么清楚了，這時(shí)，需要設(shè)計(jì)者的權(quán)衡，這種權(quán)衡恰恰是最體現(xiàn)設(shè)計(jì)者內(nèi)功的地方。難怪有人說(shuō)，軟件設(shè)計(jì)也是門(mén)藝術(shù)，因?yàn)殡S時(shí)隨地你都可能碰到需要權(quán)衡的地方！(每個(gè)程序員都希望當(dāng)架構(gòu)師，但是架構(gòu)師并不是那么好當(dāng)，因?yàn)榧軜?gòu)師就像一個(gè)藝術(shù)家一樣，需要做非常多恰當(dāng)?shù)臋?quán)衡。如果任何人都能作出和你同等水平的決策，那你設(shè)計(jì)的這個(gè)決策便不值錢(qián)了。軟件的藝術(shù)之美源于權(quán)衡(Trade-off))

總結(jié)

以上是生活随笔為你收集整理的不要为框架作过多的假设的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。