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