這兩天遇到的一些問題，引起的一些思考，覺得有必要寫下來。
一. 面向?qū)ο蟮腁PI接口設(shè)計(jì)，如何做到向后兼容。一個軟件存在多個模塊，如果提供基礎(chǔ)API的模塊變化了，那么依賴于它的應(yīng)用模塊都必須重新編譯和部署。這就對基礎(chǔ)API模塊的向后兼容性提出了要求。完全通用的方法是不存在的，任何方法都需要根據(jù)實(shí)際情況調(diào)整，這里僅僅提供一些比較通用但是也不明確的方法：
方法一：擴(kuò)展時對象只增加方法和屬性，原有的屬性和方法保留。這對于c++等基于二進(jìn)制對象布局的方法在使用時需要非常小心，否則極易引起內(nèi)存訪問違規(guī)。但是對于ActionScript基于元數(shù)據(jù)的語言來說，這一方法一般不會有什么問題。對于Java的情況不是非常清楚，估計(jì)與actionscript情況差不多。
方法二：增加新的對象（使用繼承）提供擴(kuò)展功能，原來的對象保留。不過對于耦合的類關(guān)系，只增加一個類往往并不能達(dá)到目的。
這里必須注意的一點(diǎn)是，API提供者與API使用者保持單向依賴的關(guān)系，API不應(yīng)該依賴于具體的應(yīng)用。對于多模塊的軟件來說架構(gòu)最重要的是兩點(diǎn)：
1. 從需求中抽象出API，并且將API的開發(fā)交給素質(zhì)較高的人員，而應(yīng)用之間松散耦合，通過API發(fā)生關(guān)系。
2. API本身空間也要做劃分，將之切割成為正交的空間，這樣API擴(kuò)展時，影響控制在局部。
順便說說向前兼容的問題，這要求新的Client兼容老的API，這在API設(shè)計(jì)中很少碰到，但是在設(shè)計(jì)軟件的文檔存儲格式（Save/Load）時常常遇到，這要求新的應(yīng)用在開發(fā)時，做判斷，判斷屬性不存在時應(yīng)該如何處理，也就是提供一個默認(rèn)值。
對于其它的Server-Client結(jié)構(gòu)，比如WebService的擴(kuò)展，XML擴(kuò)展等等，我想也應(yīng)該有類似的方法。所以我也想去看看一些公開的API接口是如何設(shè)計(jì)和擴(kuò)展的，比如FaceBook，不過說到底還是抽象與空間劃分的問題，而這些并沒有通用的方法，都依賴于具體的需求。
二. 面向接口的設(shè)計(jì)實(shí)際上就是合理的劃分對象空間。對于對象在擴(kuò)展時，我們常常會發(fā)現(xiàn)并沒有辦法把它劃分成樹狀的類關(guān)系，常常我們發(fā)現(xiàn)從一個類A派生了兩個類B和C，但是又存在第三種情況，它的行為包含部分B的行為也包含部分C的行為。實(shí)際上類的空間劃分，和數(shù)據(jù)庫設(shè)計(jì)是一樣的，每一次劃分（繼承）相當(dāng)于以一個索引劃分對象空間，但是很多時候劃分有多個索引，這時候要想劃分成單一的一棵樹是不可能的。這時候就需要進(jìn)一步細(xì)化對象的空間劃分，并將之劃分為正交的多個空間。舉個例子：Window派生出TransparentWindow和OpaqueWindow，這是一種劃分，但是我們又發(fā)現(xiàn)另一種劃分，WindowWithTitleBar與WindowWithoutTitleBar，他們都是對Window的劃分。這時候我們應(yīng)該想到的是，Window可以拆分為：ITitleBar, IMainWindow，各種Window可以選擇實(shí)現(xiàn)或者不實(shí)現(xiàn)這些接口。當(dāng)?shù)谌呤褂眠@些對象時，直接訪問接口即可，因?yàn)槠渌慕涌诳赡苁撬麄儾⒉魂P(guān)心的。當(dāng)存在多種索引時，將對象拆分為正交的空間，每一個空間尤其自己的單一索引，這應(yīng)該是對象劃分的一種通用原則。就像單根繼承一樣，這樣會使得對象的劃分結(jié)構(gòu)非常清晰。
對于某些不是特別復(fù)雜的情況，如果存在多種劃分索引，不妨用單一的類表示全部的對象，對某些對象，某些屬性方法是無效的，這樣實(shí)際上在簡單情況下是很有效的，因?yàn)檫^度的劃分會造成復(fù)雜性，使用者可能不知道在哪個對象上找到他需要的屬性或方法了，這就好像在一張表上設(shè)計(jì)了全部的屬性，盡管有些屬性是抵觸的，有些屬性是相關(guān)的。隨著不斷的擴(kuò)展，這張表會越來越大，這就需要開始對對象空間做劃分了，所以說到底，還是一個需求復(fù)雜度的問題，這里最重要的是掌握一個劃分的度，何時劃分，劃分到什么程度，決定這些的往往不僅僅是技術(shù)因素，還有商業(yè)上，運(yùn)營上，時間上，成本上的因素，這也是最難判斷的一點(diǎn)，需要在實(shí)際中去具體問題具體分析，這里就能體現(xiàn)經(jīng)驗(yàn)的重要性了，其實(shí)在架構(gòu)上方法都是很Genralized的，這些和實(shí)現(xiàn)一個具體的算法大部相同，所以設(shè)計(jì)模式都在講模式一定有其上下文，也是這個道理嗎
胡扯了很多，先到這里吧，等有時間做進(jìn)一步的整理
http://www.aar.cn/wallpaper/Desktop/Natural/2150/F_WQTP_1680x1050_Q.Html
http://opensource.adobe.com/wiki/display/site/Source
Fellow evangelist Duane Nickull has posted the slides from his
Web 2.0 Design Patterns, Models and Analysis presentation