posts - 6,  comments - 9,  trackbacks - 0

这几天总算有点时间,可以看看手头的书了。

手头一直有本书从买来就没有翻一下——《 expert one-on-one J2EE Development without EJB 》,这几天没事翻了一下。觉得大师就是大师一上来就把我们的苦衷说的清清楚楚,还是实践出真理阿。

最让我记忆犹新的是这几句话:

 

       检验一个体系结构是否合理,判断一种实现选择是否合适,都要看他是否符合这一主旋律。

       主旋律是:

²        简单

²        高产

²        面向对象为本

²        业务需求至上

²        重视检验过程

²        重视可测试性


所谓的主旋律,个人理解就是一种审美观点,就像大家看到漂亮的 MM 一样,为什么 MM 这么漂亮,因为他符合人们对漂亮的机电看法
——
国色天香 倾城倾国 沉鱼落雁 闭月羞花 如花似玉 花容月貌 美若天仙 艳如桃李。。。反正就是美。

从设计模式角度说明主旋律,就是设计中常常遵守的几点原则——可维护性,可扩展性,可复用性,要面向接口去设计,等等。

以上这些都是从理论角度出发考虑的,而 Rod Johnson 是从实践的角度来考虑问题,大学学了点哲学原理都运用在这里了。以前在设计第一个框架的时候没有太多的考虑到程序员的实用型,只是为了设计而设计,最后把框架设计的及其复杂,最后的结果只有进行重新设计,进行框架的重构。而在设计中遇到的问题很多是 Rod 在书中描述的场景,真是深有感触阿。

²        简单

设计中常常应该遵守 2/8 原则,系统中 80% 是最长用的,应该以这 80% 为重点去设计,如果只是为了设计中的完美而过多地考虑其他的 20% 就会陷入复杂的漩涡。就拿我们现在设计的 JBrain (我们的框架代号)框架中的元数据系统来说把,本来是为了对系统中的所有元素的一个建模过程,涉及到显示模型建模,业务模型建模,数据模型建模,工作流模型建模,(这个就好比在基础框架基础上又抽象出一层),我们在建模中就是考虑到那 80% 常见的情况,对模型系统进行设计,但是每一个业务都会涉及到报表系统,这就是那 20% 的情况,如果我们再花精力去研究报表系统的建模,就会把自己带入无比复杂的深渊中,所以我们决定用这 80% 的模型建模来描述这 20% 的报表建模,这样问题就简单多了,对于报表的设计来说,虽然有点麻烦,但是我们的设计可以适应大多数的情况。实际只要我们作一些辅助的工具就可以简化报表模型的建模,这是我们在框架开发的后期发现的,经过实践证明我们当初的想法是真确的。

这种情况还出现在我们当初在做一个业务系统的时的框架选择上,当时我们为了框架能够承受更大的负载度,而考虑使用 EJB 的多层开发(幸运的是没有用实体 Bean ),这使我们的开发量整整增加的一倍,还在不考虑测试的情况下。项目结束了上线使用,用户根本没有当初设想的并发量,我们当时真的还考虑了 Rod 所说的是否能够在客户端支持 Swing 程序,幸亏后来被否定了。有时候我们在设计中总是追寻完美,为了设计而设计,这种做法正如 Rod 所说的是不科学的。

简单才是美,因为简单出现了 POJO 对象,因为简单出现了 Hibernater ,因为简单出现了 Annotation ,因为简单出现了 EJB3.0 。因为简单才是 java 的开源社区如火如荼,人声鼎沸。

 

²        高产

有时候,设计者注重的是设计,这也是我们设计中常常存在的一种习惯,程序员总是追求完美,追求 perfect ,而一个企业在完成项目中要的是生成率,要的是质量,一个功能用那种完美的框架需要 2 周的时间才能开发完,而使用简单的框架只需要 3 天的时间就可以完成了,你说我们应该使用那种框架。

去年在开发一个项目的时候,因为我们是和其他部门一起合作开发,在项目开始的调研当中,我们极力推荐使用我们的 JBrain 元数据框架,而另为一个部门却强调使用 JSF 所建立的框架( JSF 刚出来,而且那个部门的人员还没有太多的理解 JSF 的深刻含义,他们觉得 JSF 非常好,非常的完美),最后因为我们的框架是黑盒的,客户不想把他们的项目绑死在我们的框架上,所以最后决定使用 JSF 来设计框架(不说开发一个企业级框架所需要的时间),这里我不是说 JSF 不好,我研究过 JSF ,觉得他的设计哲学真的很好,尤其他的组件树和生命周期设计的非常完美,尤其他的 Render 机制,真的就是我们以前在使用 jsp Tag 的时候一直想要又没有的功能(我们框架中的显示模型有很多思想是从他的组件数概念而来的),但是如果用 jsf 开发企业级程序,而且是在国内这种客户要求非常苛刻的情况下是非常不足的。因为我们的 JSF 框架是在 Apache MyFace 基础上开发的,实际上后来他的标签我们没有用多少,大部分都是我们自己在他的基础上重新开发的。后来框架设计出来了,生产率太低,完成一个工作需要做很多很多的事,我实在看不下去了,看着我周边的同事一边又一边的叹气(而且项目结束前几乎是天天加班到 9 点),根据我们原有框架的元数据原理,写了一个 JSF 框架的代码生成机,这才把生产率稍微提上了一点。

实际有时候我们设计框架的时候不必要考虑过多,一定要从开发和实用的角度去考虑,多考虑一下程序员的工作方式。

 

       今天就写到这里,可能是和 Rod Without EJB 中的想法产生了共鸣才有了这么多费话,其他的感触将在后续的随笔中写到。写这篇文章也是为了提醒自己开发的时候一定要从实际出发,一切的灵感都是来源于实践的。

posted on 2006-05-31 23:18 我爱夏花,更爱秋叶 阅读(1243) 评论(0)  编辑  收藏 所属分类: 设计模式

只有注册用户登录后才能发表评论。


网站导航:
 
<2006年5月>
30123456
78910111213
14151617181920
21222324252627
28293031123
45678910

又回到了夏花的时节了!我又回来了:)

常用链接

留言簿(1)

随笔分类

随笔档案

不错的blog

不错的网站

搜索

  •  

最新评论

阅读排行榜

评论排行榜