設(shè)計(jì)的時(shí)候應(yīng)該考慮哪些問(wèn)題？這個(gè)問(wèn)題的答案，如果用一句話來(lái)解符號(hào)，那答案就是：要仔細(xì)考慮使用這個(gè)框架的人感受，要考慮如何讓使用者感覺(jué)爽的問(wèn)題。當(dāng)然如果是三天兩天說(shuō)不清楚的方式，那就得從方法論，問(wèn)題領(lǐng)域，設(shè)計(jì)原則等待進(jìn)行闡述了。

怎樣才是一個(gè)及格的框架？這個(gè)問(wèn)題，用一句話解釋，就是在滿足上一個(gè)問(wèn)題的情況下不違背基本設(shè)計(jì)原則，那么就可以算是一個(gè)及格的框架。如果用三天兩天說(shuō)明，那就要把所有的基本設(shè)計(jì)原則拿出來(lái)，一個(gè)個(gè)講講清楚，一個(gè)個(gè)說(shuō)說(shuō)明白。

如果滿足了第一個(gè)條件，使用者是滿意的，從使用來(lái)說(shuō)是不錯(cuò)的；如果滿足了第二個(gè)條件來(lái)說(shuō)，從設(shè)計(jì)及實(shí)現(xiàn)來(lái)說(shuō)是不錯(cuò)的。如果兩個(gè)都滿足了那說(shuō)明，最起碼是可用的及格的框架，當(dāng)然也可能得分更多。

開(kāi)源框架的體系與戰(zhàn)術(shù)

順便，今天還談?wù)効蚣艿捏w系與戰(zhàn)術(shù)性角度，一家之言，說(shuō)得不對(duì)還請(qǐng)海涵。

從軍事上來(lái)說(shuō)，戰(zhàn)術(shù)性的戰(zhàn)斗就是具體的一塊無(wú)關(guān)緊要的戰(zhàn)斗，勝就勝了，敗就敗了，局部互有長(zhǎng)短，但是就全局來(lái)說(shuō)沒(méi)有本質(zhì)的影響；而體系性的則是影響雙方勢(shì)力對(duì)比的重要關(guān)鍵點(diǎn)，是個(gè)死去活來(lái)的問(wèn)題，是西風(fēng)壓倒東風(fēng)還是東風(fēng)壓倒西風(fēng)的問(wèn)題。

做框架也是有同樣的問(wèn)題的，如果框架只能解決一個(gè)局部部分，或者說(shuō)具體問(wèn)題，那么就是戰(zhàn)術(shù)性框架；比如一個(gè)Xml解析器，一個(gè)網(wǎng)絡(luò)爬蟲(chóng)框架等等，都是解決具體問(wèn)題的，因此不管做得怎么到位，怎么好，都是一個(gè)戰(zhàn)術(shù)性的問(wèn)題。

那么我再拿人們常說(shuō)SSH框架來(lái)說(shuō)，很明顯Hibernate和Struts是屬于戰(zhàn)術(shù)性框架的。但是Spring則明顯不同，表面上Spring本身只是提供了一系列的機(jī)制和體系，但是它本身并不做具體的某個(gè)方面的問(wèn)題，他解決IOC,AOP之類的比較虛的問(wèn)題，但是正因?yàn)槿绱?，它占?jù)了整個(gè)開(kāi)源框架的核心位置，許許多多的別的框架都是非常容易被替換及剔除的，但是唯一的要剔除Spring就比較困難--或者說(shuō)，剔除Spring，就需要找一個(gè)比Spring更好的方案來(lái)替代，沒(méi)有找到之前，就很難真正剔除它。

偶也看了OSC上一些同學(xué)的框架的源代碼，從解決具體的問(wèn)題來(lái)說(shuō)，技巧、慎密性、前衛(wèi)性都不錯(cuò)，但是看來(lái)看去，感覺(jué)還是在戰(zhàn)術(shù)性問(wèn)題上打轉(zhuǎn)轉(zhuǎn)，也就是解決具體問(wèn)題方面做得非常不錯(cuò)，但是在體系性方面就比較弱了。

在此，我也把自己對(duì)框架(Framework)的理解和大家交流，我的理解Framework一定是Framework框架者構(gòu)建的結(jié)構(gòu)性、體系性、機(jī)制性的部分，而讓使用者提供實(shí)際的、業(yè)務(wù)的、具體的實(shí)現(xiàn)的部分；當(dāng)然Framework構(gòu)建者也可以提供一些實(shí)際的、業(yè)務(wù)的、具體的實(shí)現(xiàn)的部分，但是這只可以作為默認(rèn)的、基本的實(shí)現(xiàn)，它在大多數(shù)的情況下都是夠用的，但是在特殊情況下是可以被拿掉的，是可以被替換的。

也就是說(shuō)，如果你達(dá)到上面要求，你才可以說(shuō)是一個(gè)框架(Framework)，否則，你只是個(gè)Library，只是一個(gè)代碼庫(kù)，不能稱之為一個(gè)框架。

可能有的同學(xué)們又說(shuō)了，你呼扯海說(shuō)了半天，你現(xiàn)在設(shè)計(jì)的框架怎么就是有體系性的了？？這正是我下面要解釋的問(wèn)題：

通過(guò)大量的體系性上思考，它不僅立足于解決開(kāi)發(fā)問(wèn)題，還考慮集成、發(fā)布、維護(hù)方面的問(wèn)題。
構(gòu)建了許多子框架，比如：流程框架，插件框架、UI框架等等，這些框架只有體系和機(jī)制及規(guī)范方面的內(nèi)容，本身是不提供具體功能的，但是業(yè)務(wù)開(kāi)發(fā)人員可以基于其之上進(jìn)行擴(kuò)展，來(lái)達(dá)成各種目標(biāo)。
在在實(shí)現(xiàn)方面大都考慮有侵入性及無(wú)侵入性，也就是說(shuō)如果你可以接受侵入性，那你就做起來(lái)更方便；如果你不接受侵入性，那么也可以使用Tiny框架的許多功能。
在集成方面下的功夫是最大的，可以方便實(shí)現(xiàn)自組裝，也就是扔進(jìn)去不用管的模式。
在模塊化方面也是投入大量的力量，所有的資源都可以打入Jar包，不必修改web.xml就可以進(jìn)行各種Web模板的加載等待。
戰(zhàn)略性目標(biāo)是構(gòu)建一個(gè)生態(tài)圈，做UI的，做邏輯的，做業(yè)務(wù)的能夠做自己擅長(zhǎng)的事情，通力協(xié)作。

所以，正因?yàn)門(mén)iny框架做了許多體系性的工作，可能不能直接實(shí)現(xiàn)某個(gè)功能，但是它的作為體系在開(kāi)發(fā)、協(xié)作、維護(hù)、支持各個(gè)階段。

當(dāng)然，我們正在設(shè)計(jì)的框架中也包含了大量的解決實(shí)際問(wèn)題的庫(kù)和框架，同時(shí)也不拒絕各種開(kāi)源框架的集成與使用。

因此，大的開(kāi)發(fā)框架是個(gè)體系性的工程。所以，做開(kāi)源框架之前，先要定位準(zhǔn)確，是做戰(zhàn)術(shù)性的還是體系性的框架，這樣只做自己擅長(zhǎng)，可控的事情，才得心應(yīng)手，輕松愉快，同時(shí)又可以獲得最大回報(bào)。

上一篇：與屈原對(duì)話及開(kāi)源精神下一篇：教計(jì)算機(jī)程序解數(shù)學(xué)題