先看這個(gè)文章，“最小接口”：
http://blog.csdn.net/mfowler/archive/2006/10/19/1340364.aspx
Martin
Fowler的確是oo的大師，對(duì)類的理解和解析的確很深入，但是我還是想表述一些不同的意見。對(duì)于class而言，越強(qiáng)大就會(huì)越臃腫，越簡(jiǎn)單就會(huì)越零
碎，這是不可避免的問題。對(duì)于一個(gè)足夠復(fù)雜的系統(tǒng)，class簡(jiǎn)單了不行，太散，最后的組裝成本會(huì)相對(duì)過高，復(fù)雜了也不行，復(fù)用和維護(hù)的成本也很高。而且
這兩種都會(huì)造成中間層的脂肪過剩，雖然所有講oo的書都會(huì)說過度復(fù)雜的中間層不好，但是沒有哪本書提出了很好的解決辦法，似乎歸結(jié)到最后就只有依靠開發(fā)者
本身了。這種情況其實(shí)很是可怕，面對(duì)目前的開發(fā)現(xiàn)狀，很多系統(tǒng)對(duì)復(fù)用的渴求會(huì)越來越明顯，但是老系統(tǒng)中到底有多少模塊可以無縫移植，只怕沒有人能說清楚。
而且隨著需求的變化，老系統(tǒng)的維護(hù)和升級(jí)也越來越成為一個(gè)巨大的負(fù)擔(dān)，重寫是最常見的最終武器，但這武器所帶來的損耗和浪費(fèi)也是相當(dāng)驚人的。
其實(shí)問題的核心是：如何在復(fù)雜度和可讀性之間尋求最佳的平衡。人的腦容量是有限的和有差異的，不同的開發(fā)者對(duì)復(fù)雜度的衡量標(biāo)準(zhǔn)是不一樣的。一個(gè)確定的模
塊，對(duì)某些人而言是容易理解和消化的，但對(duì)另外的人而言卻復(fù)雜的無法吞咽，這是現(xiàn)實(shí)問題，并不是通過培訓(xùn)和努力就能消除的。不同的行業(yè)和不同的開發(fā)方向，
一定會(huì)造成不同的理解范圍和理解方式，也就造成不同的開發(fā)者之間會(huì)存在必然的差異。只要這種差異存在，之前所述的問題就一定存在。
問
題不可怕，可怕的是不敢去面對(duì)。真的勇士，敢于直面慘淡的人生;-)
個(gè)人看法，膠合層是一定要減肥的，但是如何減是一個(gè)問題。對(duì)于一個(gè)oo構(gòu)架的系統(tǒng)，膠合層是一定存在的，如何做薄做小是個(gè)關(guān)鍵，同時(shí)薄和小的標(biāo)準(zhǔn)也是因人
而異的。起碼有一點(diǎn)我很肯定，膠合層的復(fù)用性是很差的，甚至可以說根本沒有復(fù)用的可能，那么很簡(jiǎn)單，一個(gè)系統(tǒng)中只創(chuàng)建一個(gè)膠合層，盡量將特定的需求和無法
復(fù)用的部分整合進(jìn)來，同時(shí)隨時(shí)做好丟棄的準(zhǔn)備，一旦需要開發(fā)新系統(tǒng)或者需要升級(jí)系統(tǒng)，膠合層就成為第一個(gè)被犧牲的對(duì)象，如果設(shè)計(jì)的好，就有可能是唯一需要
丟棄的部分，這樣起碼可以保證智力投資最大限度的保值。
模塊(class，接口，函數(shù)，隨便你怎么定義它)的復(fù)用性如何，決定了它的
生存時(shí)間，也直接反應(yīng)了開發(fā)者的能力，如何確保復(fù)用性是個(gè)老生常談的話題了，但我還是要啰嗦兩句。復(fù)用性好并不代表強(qiáng)大和復(fù)雜，為了追求一個(gè)萬能模塊而編
寫足夠復(fù)雜的模塊，純屬浪費(fèi)時(shí)間和精力，簡(jiǎn)單是保證良好復(fù)用性的前提，一個(gè)復(fù)雜的模塊是不能指望有多少復(fù)用性的。同時(shí)，簡(jiǎn)單并非是簡(jiǎn)化，一個(gè)無法完成分內(nèi)
工作的模塊是殘次品，是不能稱之為具有復(fù)用性的。基于之前的論述，如何算是簡(jiǎn)單對(duì)于不同的開發(fā)者而言又是各不相同的，這需要開發(fā)者從別人的角度考慮和長時(shí)
間的自我衡量，復(fù)雜了不行，學(xué)習(xí)難度太高，簡(jiǎn)單了不行，會(huì)降低模塊的靈活性。曾經(jīng)看過一段話：好的界面就是一眼看過去，需要的功能都在，沒有什么復(fù)雜的存
在，但是需要深入控制的時(shí)候，該有的也都能找的到。挪到我們的問題上，也就差不多是這個(gè)意思了。這很難，但就是因?yàn)殡y，也就同時(shí)創(chuàng)造了樂趣，做為一個(gè)開發(fā)
者，當(dāng)以這種困難為敵手，圖窮匕首現(xiàn)，五步濺血.....
2006-10-19 18:57