先看這個文章，“最小接口”：
http://blog.csdn.net/mfowler/archive/2006/10/19/1340364.aspx

　 　Martin Fowler的確是oo的大師，對類的理解和解析的確很深入，但是我還是想表述一些不同的意見。對于class而言，越強(qiáng)大就會越臃腫，越簡單就會越零 碎，這是不可避免的問題。對于一個足夠復(fù)雜的系統(tǒng)，class簡單了不行，太散，最后的組裝成本會相對過高，復(fù)雜了也不行，復(fù)用和維護(hù)的成本也很高。而且 這兩種都會造成中間層的脂肪過剩，雖然所有講oo的書都會說過度復(fù)雜的中間層不好，但是沒有哪本書提出了很好的解決辦法，似乎歸結(jié)到最后就只有依靠開發(fā)者 本身了。這種情況其實很是可怕，面對目前的開發(fā)現(xiàn)狀，很多系統(tǒng)對復(fù)用的渴求會越來越明顯，但是老系統(tǒng)中到底有多少模塊可以無縫移植，只怕沒有人能說清楚。 而且隨著需求的變化，老系統(tǒng)的維護(hù)和升級也越來越成為一個巨大的負(fù)擔(dān)，重寫是最常見的最終武器，但這武器所帶來的損耗和浪費也是相當(dāng)驚人的。

　 　其實問題的核心是：如何在復(fù)雜度和可讀性之間尋求最佳的平衡。人的腦容量是有限的和有差異的，不同的開發(fā)者對復(fù)雜度的衡量標(biāo)準(zhǔn)是不一樣的。一個確定的模 塊，對某些人而言是容易理解和消化的，但對另外的人而言卻復(fù)雜的無法吞咽，這是現(xiàn)實問題，并不是通過培訓(xùn)和努力就能消除的。不同的行業(yè)和不同的開發(fā)方向， 一定會造成不同的理解范圍和理解方式，也就造成不同的開發(fā)者之間會存在必然的差異。只要這種差異存在，之前所述的問題就一定存在。

　　問 題不可怕，可怕的是不敢去面對。真的勇士，敢于直面慘淡的人生;-) 個人看法，膠合層是一定要減肥的，但是如何減是一個問題。對于一個oo構(gòu)架的系統(tǒng)，膠合層是一定存在的，如何做薄做小是個關(guān)鍵，同時薄和小的標(biāo)準(zhǔn)也是因人 而異的。起碼有一點我很肯定，膠合層的復(fù)用性是很差的，甚至可以說根本沒有復(fù)用的可能，那么很簡單，一個系統(tǒng)中只創(chuàng)建一個膠合層，盡量將特定的需求和無法 復(fù)用的部分整合進(jìn)來，同時隨時做好丟棄的準(zhǔn)備，一旦需要開發(fā)新系統(tǒng)或者需要升級系統(tǒng)，膠合層就成為第一個被犧牲的對象，如果設(shè)計的好，就有可能是唯一需要 丟棄的部分，這樣起碼可以保證智力投資最大限度的保值。

　　模塊(class，接口，函數(shù)，隨便你怎么定義它)的復(fù)用性如何，決定了它的 生存時間，也直接反應(yīng)了開發(fā)者的能力，如何確保復(fù)用性是個老生常談的話題了，但我還是要啰嗦兩句。復(fù)用性好并不代表強(qiáng)大和復(fù)雜，為了追求一個萬能模塊而編 寫足夠復(fù)雜的模塊，純屬浪費時間和精力，簡單是保證良好復(fù)用性的前提，一個復(fù)雜的模塊是不能指望有多少復(fù)用性的。同時，簡單并非是簡化，一個無法完成分內(nèi) 工作的模塊是殘次品，是不能稱之為具有復(fù)用性的。基于之前的論述，如何算是簡單對于不同的開發(fā)者而言又是各不相同的，這需要開發(fā)者從別人的角度考慮和長時 間的自我衡量，復(fù)雜了不行，學(xué)習(xí)難度太高，簡單了不行，會降低模塊的靈活性。曾經(jīng)看過一段話：好的界面就是一眼看過去，需要的功能都在，沒有什么復(fù)雜的存 在，但是需要深入控制的時候，該有的也都能找的到。挪到我們的問題上，也就差不多是這個意思了。這很難，但就是因為難，也就同時創(chuàng)造了樂趣，做為一個開發(fā) 者，當(dāng)以這種困難為敵手，圖窮匕首現(xiàn)，五步濺血.....

2006-10-19 18:57