db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dibyendu Majumdar <dibye...@mazumdar.demon.co.uk>
Subject Re: Reducing module dependencies
Date Mon, 11 Feb 2008 21:23:34 GMT

On 11 Feb 2008, at 04:59, Daniel John Debrunner wrote:

>> 2) A somewhat similar but different issue is that all the Stored  
>> Format Ids of all objects, regardless of layer, module, etc., is  
>> stored in org.apache.derby.iapi.services.io.StoredFormatIds. In  
>> this case, it is probably better to externalize this information  
>> and load it at system startup.
>
> Not sure what you mean here, these are just constants so not sure  
> what it means to load it at system startup. One issue with  
> distributing information is ensuring that different modules do not  
> define identical values in the same space. That's really the  
> purpose of StoredFormatIds (and some similarly shared classes), to  
> ensure a single allocation for each value.

Hi Dan,

It seems to me that the current solution is trying to solve following  
problems:

a) Store reference data in one place so that issues such as  
duplication can be avoided.
b) Having reference data in one place also acts as documentation, in  
the sense that it helps to check things, etc.
c) The use of constants is also good for performance, as no further  
lookup is necessary.

I think that each of these objectives could be met by a solution that  
stores the reference data in external files, and loads them at  
startup. In logical terms, a potential solution would be as follows:

Let's assume that there is a component that has following  
responsibilities:

Load a set of key/value pairs from externally defined files into a  
hash table.
Provide access to the values by key.
Allows keys to be grouped by namespaces.

Let's also assume that the data load happens when this component is  
initialized, i.e., using a static initializer.

Modules that need to have their own set of "constants", can  
initialize them as follows:

static final String A_CONSTANT = Component.get("namespace", "my.key");

The advantage of this approach over the current approach is that:

a) It maintains all the objectives of the current approach. Data can  
be stored in a shared location, and therefore, we can avoid problems  
such as use of duplicate values.
b) It ensures efficient access by allowing modules to continue using  
constants for such values.
c) It makes the system more modular, as each module references only  
those constants that it defines itself - there is no need for a  
shared interface that defines all constants.

I don't see any particular disadvantage in taking this approach.


Regards

Dibyendu


Mime
View raw message