HTLL技术设计原则

    HTLL 设计原则    设计不管你是否使用HTTL，都欢迎看一下此设计文档，可能对你设计上有帮助，因为设计理念是相通的。静态视图查看大图模型划分原则按实体域，服务域，会话域划分。不管你做一个什么产品，都一定有一个被操作的主体，比如：服务框架管理的Service，任务框架管理的Task，Spring管理的Bean等，这就是实体域。即然有被操作者，就一定有操作者，它管理被操作者的生命周期，发起动作，比如：服务框架的ServiceInvoker,，任务框架的TaskScheduler，Spring的BeanFactory等，这就是服务域。服务域发起动作，在执行过程中，会有一些临时状态需要存储交换，比如：Invacation，Execution，Request等，这就是会话域。相应的，在HTTL中：· Engine 为服务域 · 它是API的入口，并负责实体域Template的生命周期管理，它是Singleton单一实例的，加载后不可变，所以是线程安全的，它的初始化过程较重，请复用单例。· Template 为实体域 · 代表着被操作者，它是Prototype原型实例的，即每个模板产生一个实例，加载后不可变，同样也是线程安全的，模板变化后，将产生不同的实例，而不改变原实例。· Context 为会话域 · 持有操作过程中的所有可变状态，它是ThreadLocal线程内实例的，即不和其它线程竞争使用，所以也是线程安全的，请不要跨线程传递，它的初始化过程很轻量，每次模板执行前都新建实例，执行完即销毁。这样划分的好处是，职责清晰，可变状态集中，每个域都是无锁线程安全的，保证在大并发下，不会降低系统的活性。这些核心领域模型也就是HTTL的API(Application Programming Interface)，它是HTTL暴露给用户的最少概念，也就是上面类图中的第一列。扩展点组装原则按“微核+插件”体系组装。但凡有生命力的产品，都是在扩展性方面设计的比较好的，因为没有哪个产品可以覆盖所有需求，对于开源软件尤其如此。所以，产品只有具有良好的扩展性，允许用户或第三方参与进来，进行二次开发，才能保持生命力。怎么样的扩展性才是最好的？通常来讲，就是没有任何功能是硬编码的，所有的功能都可被用户替换。那要如何才能做到这样？一个重要的原则就是：平等对待第三方。也就是凡是原作者能实现的功能，第三方也要能够在不改变源代码的前提下实现。换言之，原作者应把自己也当作扩展者，自己添加功能时，也要用第三方扩展者同样的方式进行，而不要有特权。要做到这一点，就需要一个良好的框架支撑，“微核+插件”是一个不错的选择，Eclipse, Maven等知名软件都采用该体系。什么是“微核+插件”？微核，即最小化核心，内核只负责插件的组装，不带任何功能逻辑，所有功能都由可替换的插件实现，并且，组装过程应基于统一的规则，比如基于setter注入，而不能对不同插件硬编码组装，这样可以确保没有任何功能在内核中硬编码。比如：Spring, OSGI, JMX, ServiceLoader等都是常见的微核容器，它们负责基于统一规则的组装，但不带功能逻辑。当然，如果你不想带这么重的框架，也可以自行实现，HTTL就采用自行实现的httl.util.BeanFactory作为组装微核。在Engine.getEngine()中调用了BeanFatory.createBean(Engine.class, properties)，其中，properties即为httl.properties配置，BeanFatory基于setter方法，递归注入所有对象的属性。比如：httl.properties中配置了parser=httl.spi.parsers.CommentParser，而DefaultEngine中有setParser(Parser parser)方法，就会被注入，并且Parser本身的属性也会递归注入。如果你需要扩展或替换HTTL的实现，请参见：扩展集成既然非功能性的插件组装过程，可以由微核框架来完成，那功能性的组装怎么办呢？ 我们应该把功能性的组装过程也封装成插件，即让大插件组装小插件，形成级联组装关系。 比如，HTTL的入口类Engine的实例也是一个插件，它负责模板的缓存，加载，解析的总调度，即你可以替换DefaultEngine实现。 只需在httl.properties中配置：engine=com.your.YourEngine，可以将现有Parser等SPI注入你的Engine。这些插件的接口，也就是HTTL的SPI(Service Provider Interface)，它是HTTL暴露给扩展者的最小粒度的替换单元，也就是上面类图中的第二列。整体分包原则按复用度，抽象度，稳定度分包。· 复用度： · 每种用户所需用到的类，就是同一复用粒度的，比如：使用者和扩展者，这样可以减少代码干扰，以及最大化复用。· 稳定度： · 被依赖包和依赖包的占比，如果一个包依赖很多包，那别的包变化都会引起它跟随变化，所以它就不稳定，反之即稳定， 保持被依赖者总是比依赖者的稳定度高，形成金子塔关系，这样可以防止不稳定性传染，比如a包只依赖3个包，而b包依赖10个包，那就不要让a包去依赖b包。· 抽象度： · 包中抽象类个数占比，比如包中有10个类，其中3个为抽象类(包括接口)，则抽象度为3/10， 保持包的稳定度和抽象度成正比，即把抽象类(包括接口)放到稳定的包中，把具体实现类放到不稳定的包中，这样可以保持每层都有足够的扩展性。稳定度与抽象度关系如下图：也就是分包应该如下：其中上面那个包不依赖其它包。所以它很稳定，应尽量把抽象类或接口放在这一层，而下面那个包依赖了三个包，三个包变化都会引起它跟随变化，所以它是不稳定的，应尽量把具体实现类放在这一层。因稳定度与抽象度成正比，所以不稳定度与抽象度成反比，用反比方便画图，计算方式如下：· (1) I = Ce / (Ca + Ce) · I: Instability (不稳定度)· Ca: Afferent Coupling (传入依赖，也就是被其它包依赖的个数)· Ce: Efferent Coupling (输出依赖，也就是依赖其它包的个数)· (2) A = Na / Nc · A: Abstractness (抽象度)· Na: Number of abstract classes (抽象类的个数)· Nc: Number of classes (类的个数，包括抽象类)· (3) D = abs(1 - I - A) * sin(45) · D: Distance (偏差)· I: Instability (不稳定度)· A: Abstractness (抽象度)应该保持偏差越小越好，即下图所示交点都落在绿色反比线左右：基于上面的原则，HTTL的包结构整体上划分为三层：(对应上面类图中的三列)· API (Application Programming Interface) · 模板引擎的使用者依赖的接口类，也是核心领域模型所在，保持最少概念，并隐藏实现细节，其中Engine类相当于微内核，只管理非功能性的扩展点的加载，不硬编码模板加载解析渲染的任何部分。· SPI (Service Provider Interface) · 模板引擎的扩展者依赖的接口类，它依赖于API的领域模型，它是模板引擎功能正交分解的抽象层，以保证用户可以最小粒度替换需要改写的地方，方便二次开发。· BUILT-IN (Built-in Implementation) · 内置扩展实现，它是SPI标准实现，也是可被用户替换的类，它包含引擎所有做的事，包括扩展点之间的组装过程(可替换DefaultEngine)，以确保没有功能换不掉，即平等对待扩展者。采用子包依赖父包风格，所以将API放在根目录，SPI接口独立子包，各种实现放在SPI的下一级子包中。· 使用者API导入：import httl.*;· 扩展者SPI导入：import httl.spi.*;下图是HTTL所有包的不稳定度与抽象度的比值距阵：(下图为JDepend绘制)HTTL所有核心包都是靠近反比线的，即上图中用绿色标识的点，表示分包是合理的。注：图中黑色的点为util相关包，它们不抽象，却被很多包依赖，只是内部复用代码，不影响整体设计，用户请不要依赖HTTL的util类。动态视图如果你要看代码，可以从入口类Engine和DefaultEngine开始，按此调用过程跟踪。获取模板过程查看大图获取模板过程说明：(与上图中的序号对应)1 当从引擎中获取模板时，1.1 首先会在缓存查找是否已缓存，如果有缓存就直接返回，1.2 如果没有，则加载模板源文件为Resource对象，1.3 接着通过转换器(分为编译和解释两种)，将Resource转换成Template，1.3.1 转换的第一步是将模板解析成AST抽象语法树，1.3.2 并对静态文本进行编译前过滤，比如删除空白等，1.3.3 对解析后的Java代码进行编译，得到具体模板实现类，1.3.4 实例化模板实现类，1.4 将模板实例写入缓存，并返回给用户。渲染模板过程查看大图渲染模板过程说明：(与上图中的序号对应)1 当用户调用模板的渲染方法时，1.1 将非Map变量对象转换成Map，将非Writer或OutputStream输出对象转成Writer或OutputStream，1.2 将变量Map压入Context栈，1.3 如果有拦截器，将实际渲染过程封装成Listener，传给拦截器执行，1.3.1 拦截器执行完拦截逻辑后，调用拦截时传入的Listener，1.3.1.1 该Listener回调模板的doRender方法，执行实际渲染过程，1.4 模板中的变量，均从Context中读取，1.4.1 如果当前Context不存在，则向上一级Context中读取，1.4.1.1 如果已经是根级别Context，则向Resolver读取，1.5 模板输出变量时，先通过Formatter，将值对象转成String，1.6 再通过Filter，过虑输出String的XML特殊符等，1.7 最终，将过滤后的String输出，1.8 模板渲染结束后，将当前Conetext弹出。性能性能对比性能测试类：BenchmarkTest.java引擎模板十万次耗时每秒次数javabooks.java8,739ms11,442/shttlbooks.httl9,608ms10,407/svelocitybooks.vm41,969ms2,382/sfreemarkerbooks.ftl56,192ms1,779/ssmarty4jbooks.st65,855ms1,518/s环境：os: Mac OS X 10.8.2, cpu: 2 x 1.70GHz, mem: 4G, jvm: 1.7.0_09 -> mem: 80MHTTL的速度接近于直接用Java硬编码输出，比其它模板引擎高一个数量级。HTTL用到的JDK的Compiler，编译一个类通常需要几百毫秒，比其它模板的编译要慢，但每个模板只在加载时编译一次。以上测试，不包含H