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

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。