这几天总算有点时间,可以看看手头的书了。
手头一直有本书从买来就没有翻一下——《
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
我爱夏花,更爱秋叶 阅读(1252)
评论(0) 编辑 收藏 所属分类:
设计模式