配置继承模式

本人曾供职于一家国内的还算比较大MIS系统开发商，工作的主要内容是用一套有默认实现的模板式框架去开发一些业务应用系统。在开发的过程中，开发工作的绝大部分内容是配置和写展示用的jsp(没有其他的模板技术)。搞jsp我不在行，于是我就把目标放在了如何减少配置的工作量。这也就是配置继承模式的来源了。到今天算是小有所成，本着请共享和求教的愿望，把我的东西贴出来，希望各位JE大牛帮忙给点意见，本人不甚感激。
话归正题，所谓配置继承呢，准确的应该叫配置信息继承，是指从功能对配置信息的需要出发，按照功能、模块、系统划分建立对应的树形配置域，仿照类继承的方式（系统域是最顶层的父类，功能是最底层的子类）而配置信息获取和管理的模式。在配置继承中，强调功能对配置信息具有控制权：可添加、覆盖、删除配置项；同时配置信息又是可从父域继承而来的：共性信息可以在上级配置以达到共享的目的。除此之外，在其中还加上了以正则表达式为基础的模式的使用，有点像struts1.2以后的通配符的使用。
举例来说，假设在一个比较简单的web系统内有四个功能分别是功能1、功能2、功能3、功能4，其中功能1、功能2是属于模块A的，功能3、功能4是属于模块B的，系统数据源在JNDI中的名字是需要配置的，而且系统在现阶段只是访问一个数据库实例。我们过去的做法是直接建立一个全局共享的配置，里面写明数据源的jndi名。但是世界总是在进步，突然有一天，我们发现一个数据库已经满足不了性能的需要了，需要将一部分功能移植到另外一个新的数据库上面去。首先移的是功能4，数据库的移植和数据的交互先且不说，功能4的程序如何来改呢？我们痛苦的改了一下，凑合着能用了。但是发现移植了功能4的数据访问后还不能满足需要，打算也把功能3移植过去，于是我们又受尽了折磨的把功能3代码改的凑合能用了。但是突然有一天，我们客户对硬件做了个大升级，上了一个无比NIU的数据库，于是我们又需把所有的功能的数据库访问代码改到访问新的数据库上去，这下我们崩溃了，以前不就是白白折腾了嘛。
如果使用配置继承来说，我们首先是在系统域上配置好数据源的名字就可以，通过继承全系统使用这个数据源。到需要移植功能4的时候，我们只需要在功能4的配置信息里覆盖默认继承来的数据源的名字就可以了。移植完了功能3之后呢，我们只需要在模块B那里配置使用新的数据源，把功能4的特殊配置去掉就可以了。如果是完全的移植数据库，那么我们只需要将系统域的配置修改，并且去掉了模块B的特殊配置就可以。可以看到，配置继承是兼顾灵活和共享的一种配置信息的管理模式，特别使用于各个功能的实现的大部分配置信息是相同的情况。当然，要使用配置继承，在功能实现的时候，就需要按照功能去取配置信息的集合，而不是直接引用全局配置信息的集合，这一点和原来的编程方式是有很大的区别。
我做了个配置继承的实现，但是弄了之后个人觉得实现的太糙，而且在实现对spring、struts、hibernate的支持时由于不熟觉得有点摸不着边，因此特别希望有大牛能给一些指导意见，最好是能有感兴趣的朋友跟我一起把他做下去。我把我的实现的代码都已经传到http://code.google.com/p/pyramid/上了,现在主要实现了对XML格式的配置文件的支持，请大家多多指教。
个人MSN:mikabpeng@msn.com,欢迎大家交流。

看了.理解如下.

1:小模快配置只负责小模快的开关.
2:优先级根据父级大于子级.

因为没具体的配置,个人想了一下.只想到两种.
1:父级 A B C D 子级a b c d 都实现四个配置,在父类各配置有默认值为0的情况下,取子类的配置a,否则取父配置A.

2:也可以把,配置父为总开关A B 子类有,子1  c d e 子2 e f g

不知道我理解的对不对?请指正.

优先级是如果子级有该配置项并且父级也有该配置项时则在自级的范围内在该配置项上取子级的配置，如果子级没有的话则从父级继承。这是从类继承的继承、覆盖(override)带过来的。大模块的配置信息能够被大模块内的各小模块所继承和直接使用，因此大模块这一级应该主要配置在大模块内具有共性的配置信息；小模块内再单独配置其特性的配置信息。

这是一种泛化的配置信息管理和获取的方式，并不是仅仅只针对于数据源或者某种特定的配置信息。