??xml version="1.0" encoding="utf-8" standalone="yes"?>
手头一直有本书从买来就没有M下——?/span>
expert one-on-one J2EE Development without EJB
》,q几天没事翻?jin)一下。觉得大师就是大师一上来把我们的苦衯的清清楚楚,q是实践出真理阿?/span>
最让我记忆Ҏ(gu)的是q几句话Q?/span>
(g)验一个体pȝ构是否合理,判断一U实现选择是否合适,都要看他是否W合q一L律?/span>
L律是Q?/span>
̔
?/span>
̔
高
̔
面向对象为本
̔
业务需求至?/span>
̔
重视(g)验过E?/span>
̔
重视可测试?/span>
|
所谓的L律,个h理解是一U审观点,像大家看到漂亮?/span>
MM
一PZ?/span>
MM
q么漂亮Q因ZW合ZҎ(gu)亮的机电(sh)看法
—?/span>
国色天香
們֟們֛
沉鱼落雁
闭月花
如花似玉
花容月貌
若天仙
艛_桃李。。。反正就是美?/font>
从设计模式角度说明主旋律Q就是设计中常常遵守的几点原则——可l护性,可扩展性,可复用性,要面向接口去设计Q等{?/span>
以上q些都是从理度出发考虑的,?/span>
Rod Johnson
是从实践的角度来考虑问题Q大学学?jin)点哲学原理都运用在q里?jin)。以前在设计W一个框架的时候没有太多的考虑到程序员的实用型Q只是ؓ(f)?jin)设计而设计,最后把框架设计的及(qing)其复杂,最后的l果只有q行重新设计Q进行框架的重构。而在设计中遇到的问题很多?/span>
Rod
在书中描q的场景Q真是深有感触阿?/span>
̔
?/span>
设计中常常应该遵?/span>
2/8
原则Q系l中
80%
是最长用的,应该以这
80%
为重点去设计Q如果只是ؓ(f)?jin)设计中的完而过多地考虑其他?/span>
20%
׃(x)陷入复杂的澃涡。就拿我们现在设计的
JBrain
Q我们的框架代号Q框架中的元数据pȝ来说把,本来是ؓ(f)?jin)对pȝ中的所有元素的一个徏模过E,涉及(qing)到显C模型徏模,业务模型建模Q数据模型徏模,工作模型徏模,Q这个就好比在基框架基础上又抽象Z层)(j)Q我们在建模中就是考虑到那
80%
常见的情况,Ҏ(gu)型系l进行设计,但是每一个业务都?x)涉及(qing)到报表pȝQ这是?/span>
20%
的情况,如果我们再花_֊ȝI报表系l的建模Q就?x)把自己带入无比复杂的深渊中Q所以我们决定用q?/span>
80%
的模型徏模来描述q?/span>
20%
的报表徏模,q样问题q单多?jin),对于报表的设计来_(d)虽然有点ȝ(ch)Q但是我们的设计可以适应大多数的情况。实际只要我们作一些辅助的工具可以简化报表模型的建模Q这是我们在框架开发的后期发现的,l过实践证明我们当初的想法是真确的?/span>
q种情况q出现在我们当初在做一个业务系l的时的框架选择上,当时我们Z(jin)框架能够承受更大的负载度Q而考虑使用
EJB
的多层开发(q运的是没有用实?/span>
Bean
Q,q我们的开发量整整增加的一倍,q在不考虑试的情况下。项目结束了(jin)上线使用Q用h本没有当初设想的q发量,我们当时真的q考虑?/span>
Rod
所说的是否能够在客L(fng)支持
Swing
E序Q幸亏后来被否定?jin)。有时候我们在设计中Lq寻完美Qؓ(f)?jin)设计而设计,q种做法正如
Rod
所说的是不U学的?/span>
单才是美Q因为简单出C(jin)
POJO
对象Q因为简单出C(jin)
Hibernater
Q因为简单出C(jin)
Annotation
Q因为简单出C(jin)
EJB3.0
。因为简单才?/span>
java
的开源社区如火如|人声鼎沸?/span>
̔
高
有时候,设计者注重的是设计,q也是我们设计中常常存在的一U习(fn)惯,E序员Lq求完美Q追?/span>
perfect
Q而一个企业在完成目中要的是生成率,要的是质量,一个功能用那种完美的框枉?/span>
2
周的旉才能开发完Q而用简单的框架只需?/span>
3
天的旉可以完成了(jin)Q你说我们应该用U框架?/span>
d在开发一个项目的时候,因ؓ(f)我们是和其他部门一起合作开发,在项目开始的调研当中Q我们极力推荐用我们的
JBrain
元数据框Ӟ而另Z个部门却使用
JSF
所建立的框Ӟ
JSF
刚出来,而且那个部门的h员还没有太多的理?/span>
JSF
的深d义,他们觉得
JSF
非常好,非常的完)(j)Q最后因为我们的框架是黑盒的Q客户不x他们的项目绑d我们的框架上Q所以最后决定?/span>
JSF
来设计框Ӟ不说开发一个企业框架所需要的旉Q,q里我不是说
JSF
不好Q我研究q?/span>
JSF
Q觉得他的设计哲学真的很好,其他的lg?wi)和生命周期设计的非常完,其他?/span>
Render
机制Q真的就是我们以前在使用
jsp Tag
的时候一直想要又没有的功能(我们框架中的昄模型有很多思想是从他的lg数概念而来的)(j)Q但是如果用
jsf
开发企业E序Q而且是在国内q种客户要求非常苛刻的情况下是非怸的。因为我们的
JSF
框架是在
Apache
?/span>
MyFace
基础上开发的Q实际上后来他的标签我们没有用多,大部分都是我们自己在他的基础上重新开发的。后来框架设计出来了(jin)Q生产率太低Q完成一个工作需要做很多很多的事Q我实在看不下去?jin),看着我周边的同事一边又一边的Ҏ(gu)Q而且目l束前几乎是天天加班?/span>
9
点)(j)Q根据我们原有框架的元数据原理,写了(jin)一?/span>
JSF
框架的代码生成机Q这才把生率稍微提上了(jin)一炏V?/span>
实际有时候我们设计框架的时候不必要考虑q多Q一定要从开发和实用的角度去考虑Q多考虑一下程序员的工作方式?/span>
今天写到这里,可能是和
Rod
?/span>
Without EJB
中的x产生?jin)共鸣才有?jin)q么多费话,其他的感触将在后l的随笔中写到。写q篇文章也是Z(jin)提醒自己开发的时候一定要从实际出发,一切的灉|都是来源于实늚?/span>
在数学计中我们要求AàB点的最短\径,可能?/SPAN>A点到BҎ(gu)很多U走法,但是q求完美的我们(其是程序员Q,L希望扑ֈ一条最短的路径。设计模式也是相同,在设计中我们惌扑ֈ设计中的最短\径,也就是设计的永恒之道Q就是设计模式中常说的无名的质)(j)Q说白了(jin)Q就是如何设计才能ɾpȝ更容易扩张,更灵z,更稳定。模式追求的是一U最佳的解决Ҏ(gu)Q在q个Ҏ(gu)的指gQ我们能够跟好的d现我们所惌实现的东ѝ?BR>
数学计算的时候有一定的法则QY件设计的时候也是有一定的法则的,而这些法则,都是在追求Y件设计的守恒定律时Ş成的——什么开/闭原则,面向接口原则Q依赖倒置原则{等Q但是Y件设计中的原则也是可变的Q而且是时d展的Q要不然׃?x)出玎ͼ今天?/SPAN>spring非常火的场面Q?/SPAN>Ioc原则?BR>
数学计算是通过许多的公式推倒出l果的,但是我们求解的时候,?x)出现这U情况,Cl果Q是通过A?/SPAN>B两个公式推导出来的,模式也是一P有一些较?yu)的模式Q而这些较?yu)的模式是一些较大的模式的基?BR>
在理解模式的时候我们可以从对象的生命周期来理解?BR>
对象产生的时候需要描q对象的属性,它的存在形式Q创建模式就是用来描q这个的Q而这个对象存在就?x)和其他对象发生联系Q就?x)和其他对象发生作用Q如何描qC们之间的联系和作用就是结构模式要做的事了(jin)Q前面这些都是静(rn)态的Q对象的存在Q不可能永远?rn)止不动的,它?x)Ҏ(gu)自己的需要,完成一些动作,语言中还有动词,名词QŞ容词之分呢!模式p语言一样需要有动词来描q对象,行ؓ(f)模式是用来描述对象的行动的Q?BR>
设计模式Q实际就是一U设计中的语aQ很多的最基本的模式,是l成q种语言的基Q我们在理解模式的时候不能只是背模式Q而应该灵zȝq用他们Q让他们有机的结合在一P形成一个生动的句子。这个就好比我们学英语,不是光背一些单词,p写出一好文章的,q需要我们有语感Q理解了(jin)以后才能写出来?BR>
q个只是我对模式的一点点个h的理解,不代表所有h的观点!Q)(j)