先看这个文章，“最小接口”：
http://blog.csdn.net/mfowler/archive/2006/10/19/1340364.aspx
Martin
Fowler的确是oo的大师，对类的理解和解析的确很深入，但是我还是想表述一些不同的意见。对于class而言，越强大就会越臃肿，越简单就会越零
碎，这是不可避免的问题。对于一个足够复杂的系统，class简单了不行，太散，最后的组装成本会相对过高，复杂了也不行，复用和维护的成本也很高。而且
这两种都会造成中间层的脂肪过剩，虽然所有讲oo的书都会说过度复杂的中间层不好，但是没有哪本书提出了很好的解决办法，似乎归结到最后就只有依靠开发者
本身了。这种情况其实很是可怕，面对目前的开发现状，很多系统对复用的渴求会越来越明显，但是老系统中到底有多少模块可以无缝移植，只怕没有人能说清楚。
而且随着需求的变化，老系统的维护和升级也越来越成为一个巨大的负担，重写是最常见的最终武器，但这武器所带来的损耗和浪费也是相当惊人的。
其实问题的核心是：如何在复杂度和可读性之间寻求最佳的平衡。人的脑容量是有限的和有差异的，不同的开发者对复杂度的衡量标准是不一样的。一个确定的模
块，对某些人而言是容易理解和消化的，但对另外的人而言却复杂的无法吞咽，这是现实问题，并不是通过培训和努力就能消除的。不同的行业和不同的开发方向，
一定会造成不同的理解范围和理解方式，也就造成不同的开发者之间会存在必然的差异。只要这种差异存在，之前所述的问题就一定存在。
问
题不可怕，可怕的是不敢去面对。真的勇士，敢于直面惨淡的人生;-)
个人看法，胶合层是一定要减肥的，但是如何减是一个问题。对于一个oo构架的系统，胶合层是一定存在的，如何做薄做小是个关键，同时薄和小的标准也是因人
而异的。起码有一点我很肯定，胶合层的复用性是很差的，甚至可以说根本没有复用的可能，那么很简单，一个系统中只创建一个胶合层，尽量将特定的需求和无法
复用的部分整合进来，同时随时做好丢弃的准备，一旦需要开发新系统或者需要升级系统，胶合层就成为第一个被牺牲的对象，如果设计的好，就有可能是唯一需要
丢弃的部分，这样起码可以保证智力投资最大限度的保值。
模块(class，接口，函数，随便你怎么定义它)的复用性如何，决定了它的
生存时间，也直接反应了开发者的能力，如何确保复用性是个老生常谈的话题了，但我还是要啰嗦两句。复用性好并不代表强大和复杂，为了追求一个万能模块而编
写足够复杂的模块，纯属浪费时间和精力，简单是保证良好复用性的前提，一个复杂的模块是不能指望有多少复用性的。同时，简单并非是简化，一个无法完成分内
工作的模块是残次品，是不能称之为具有复用性的。基于之前的论述，如何算是简单对于不同的开发者而言又是各不相同的，这需要开发者从别人的角度考虑和长时
间的自我衡量，复杂了不行，学习难度太高，简单了不行，会降低模块的灵活性。曾经看过一段话：好的界面就是一眼看过去，需要的功能都在，没有什么复杂的存
在，但是需要深入控制的时候，该有的也都能找的到。挪到我们的问题上，也就差不多是这个意思了。这很难，但就是因为难，也就同时创造了乐趣，做为一个开发
者，当以这种困难为敌手，图穷匕首现，五步溅血.....
2006-10-19 18:57