随笔 - 16, 文章 - 0, 评论 - 55, 引用 - 0
数据加载中……

class的沼泽地

  先看这个文章,“最小接口”:
http://blog.csdn.net/mfowler/archive/2006/10/19/1340364.aspx

   Martin Fowler的确是oo的大师,对类的理解和解析的确很深入,但是我还是想表述一些不同的意见。对于class而言,越强大就会越臃肿,越简单就会越零 碎,这是不可避免的问题。对于一个足够复杂的系统,class简单了不行,太散,最后的组装成本会相对过高,复杂了也不行,复用和维护的成本也很高。而且 这两种都会造成中间层的脂肪过剩,虽然所有讲oo的书都会说过度复杂的中间层不好,但是没有哪本书提出了很好的解决办法,似乎归结到最后就只有依靠开发者 本身了。这种情况其实很是可怕,面对目前的开发现状,很多系统对复用的渴求会越来越明显,但是老系统中到底有多少模块可以无缝移植,只怕没有人能说清楚。 而且随着需求的变化,老系统的维护和升级也越来越成为一个巨大的负担,重写是最常见的最终武器,但这武器所带来的损耗和浪费也是相当惊人的。

   其实问题的核心是:如何在复杂度和可读性之间寻求最佳的平衡。人的脑容量是有限的和有差异的,不同的开发者对复杂度的衡量标准是不一样的。一个确定的模 块,对某些人而言是容易理解和消化的,但对另外的人而言却复杂的无法吞咽,这是现实问题,并不是通过培训和努力就能消除的。不同的行业和不同的开发方向, 一定会造成不同的理解范围和理解方式,也就造成不同的开发者之间会存在必然的差异。只要这种差异存在,之前所述的问题就一定存在。

  问 题不可怕,可怕的是不敢去面对。真的勇士,敢于直面惨淡的人生;-) 个人看法,胶合层是一定要减肥的,但是如何减是一个问题。对于一个oo构架的系统,胶合层是一定存在的,如何做薄做小是个关键,同时薄和小的标准也是因人 而异的。起码有一点我很肯定,胶合层的复用性是很差的,甚至可以说根本没有复用的可能,那么很简单,一个系统中只创建一个胶合层,尽量将特定的需求和无法 复用的部分整合进来,同时随时做好丢弃的准备,一旦需要开发新系统或者需要升级系统,胶合层就成为第一个被牺牲的对象,如果设计的好,就有可能是唯一需要 丢弃的部分,这样起码可以保证智力投资最大限度的保值。

  模块(class,接口,函数,随便你怎么定义它)的复用性如何,决定了它的 生存时间,也直接反应了开发者的能力,如何确保复用性是个老生常谈的话题了,但我还是要啰嗦两句。复用性好并不代表强大和复杂,为了追求一个万能模块而编 写足够复杂的模块,纯属浪费时间和精力,简单是保证良好复用性的前提,一个复杂的模块是不能指望有多少复用性的。同时,简单并非是简化,一个无法完成分内 工作的模块是残次品,是不能称之为具有复用性的。基于之前的论述,如何算是简单对于不同的开发者而言又是各不相同的,这需要开发者从别人的角度考虑和长时 间的自我衡量,复杂了不行,学习难度太高,简单了不行,会降低模块的灵活性。曾经看过一段话:好的界面就是一眼看过去,需要的功能都在,没有什么复杂的存 在,但是需要深入控制的时候,该有的也都能找的到。挪到我们的问题上,也就差不多是这个意思了。这很难,但就是因为难,也就同时创造了乐趣,做为一个开发 者,当以这种困难为敌手,图穷匕首现,五步溅血.....

2006-10-19 18:57

posted on 2006-10-19 21:15 cyantree 阅读(1703) 评论(2)  编辑 收藏 引用

评论

# re: class的沼泽地  回复  更多评论   

LZ见解不错,不过最终没有给出如何切薄胶合物的方法。
如果从设计一个库的角度来讲,库的核心最好仅用有限的接口就好(紧凑+正交)。然后通过胶合物wrapper来包装库的功能,提供“便利”方法。
如此,核心始终是可以复用的,而wrapper在一定程度上也可以复用,大不了扔掉重写也无所谓。
如果是设计一个应用,那么最小接口并不是必须的,应该用最合适的接口,以达到能将应用框架透明表现出来的目的。
其实OO的精髓应该是,只是那么一些子类扩展行为的地方需要继承而已,其他的一层就够了。
2006-10-20 12:23 | LOGOS

# re: class的沼泽地  回复  更多评论   

办法不是没有,只是一般人无法接受,所以就不说了
2006-10-20 23:57 | cyantree

只有注册用户登录后才能发表评论。
网站导航: 博客园   IT新闻   BlogJava   知识库   博问   管理