手头一直有本书从买来就没有翻一下——《 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 中的想法产生了共鸣才有了这么多费话，其他的感触将在后续的随笔中写到。写这篇文章也是为了提醒自己开发的时候一定要从实际出发，一切的灵感都是来源于实践的。

       在数学计算中我们要求AàB点的最短路径，可能从A点到B点有很多种走法，但是追求完美的我们（尤其是程序员），总是希望找到一条最短的路径。设计模式也是相同，在设计中我们想要找到设计中的最短路径，也就是设计的永恒之道（就是设计模式中常说的无名的质），说白了，就是如何设计才能使系统更容易扩张，更灵活，更稳定。模式追求的是一种最佳的解决方案，在这个方案的指导下，我们能够跟好的去实现我们所想要实现的东西。

       数学计算的时候有一定的法则，软件设计的时候也是有一定的法则的，而这些法则，都是在追求软件设计的守恒定律时形成的——什么开/闭原则，面向接口原则，依赖倒置原则等等，但是软件设计中的原则也是可变的，而且是时刻发展的，要不然就不会出现，今天的spring非常火的场面，Ioc原则。

       数学计算是通过许多的公式推倒出结果的，但是我们求解的时候，会出现这种情况，C结果，是通过A和B两个公式推导出来的，模式也是一样，有一些较小的模式，而这些较小的模式是一些较大的模式的基础。

       在理解模式的时候我们可以从对象的生命周期来理解。

       对象产生的时候需要描述对象的属性，它的存在形式，创建模式就是用来描述这个的；而这个对象存在就会和其他对象发生联系，就会和其他对象发生作用，如何描述他们之间的联系和作用就是结构模式要做的事了；前面这些都是静态的，对象的存在，不可能永远静止不动的，它会根据自己的需要，完成一些动作，语言中还有动词，名词，形容词之分呢！模式就跟语言一样需要有动词来描述对象，行为模式就是用来描述对象的行动的；

       设计模式，实际就是一种设计中的语言，很多的最基本的模式，就是组成这种语言的基础，我们在理解模式的时候不能只是背模式，而应该灵活的运用他们，让他们有机的结合在一起，形成一个生动的句子。这个就好比我们学英语，不是光背一些单词，就能写出一篇好文章的，还需要我们有语感，理解了以后才能写出来。

       这个只是我对模式的一点点个人的理解，不代表所有人的观点！：）