The Configuration Inheritance Pattern，Its exact name is configuration information inheritance with the template technology. Like class inheritance, the application get function’s configuration information from the parent node first, then extend and override the configuration information. The emphasis of this pattern is that function takes the full control of configuration, but functions can share their configurations through inheritance. In addition, we can use regular expression and script in the configuration file, function determines the match result of the regular expression and value of script expression. This is like the usage of wildcards in configuration file of STRUCTS 1.2.
Normally, one system can divide into several modules, and each module has several modules or functions. The relationship between the system, modules and functions determine the way of the inheritance. Like URL in web, we can give each function or module a symbol which is called the function-path. Basically, the system’s function-path is ‘/’, and the module’s function-path ends with character ‘/’. Usually, the System has many types of configuration information. So we define that the configuration of a function with a special type is a domain. Now, the Configuration Inheritance could treat as this: If we want to get information of a domain, firstly we get the function’s domain with the same type from parent according the function-path, then extend and override the item of the domain; at last we should use the function-path to get the value of regular expressions and scripts.
Comparing with the old method of configuration, we do less work but it is more powerful and convenient.
Let’s think about a sample case: the system has two modules and each module has two functions; at the development stage and early stage of running, all of the functions use the same data source; at later stage, the system may use two or more data sources because of growth of user and data. How can we fulfill the requirement without any modifying the code?
If we use the Configuration Inheritance Pattern, at the development stage and early stage of running, we could define the name of data source in the system’s domain, so every function could use the same name; if the first module use another data source lately, we could define the new data source name in the module’s domain to override the name which inherited from the system’s domain; even every function use a different data source, we just define a special name for each function. If configuration can solve the problem, just solve it using configuration.
If we use the Configuration Inheritance Pattern, there are some differences for coding: you must get the information with implicit function-path, not get the information from a global variable. The new code just like this:
ConfigDomain config = ConfigurationManager.getInformation(functionPath,configType);
Like the Spring framework is the implementation of the DI pattern, I just have finished a simple implement, I call it pyramid. You can get the code from http://code.google.com/p/pyramid/
. But I apologizes the comments are written in Chinese; I may translate them into English later. Fortunately we must write java code in English. If you have any question or advice, you can send emails to mikab at sohu dot com.