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