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 Reducing module dependencies
Date Mon, 11 Feb 2008 01:49:52 GMT

As part of my investigation for DERBY-3351 I am looking at the ways  
in which modules interact with each other.

 From an overall layered architecture viewpoint, I feel that the  
rules should be that:

Services layer should not have a dependency on or knowledge of any of  
the higher layers.
The Store layer will depend upon the Services layer, but may not  
depend on or have knowledge of any of the higher layers.
The Language layer (compilation and execution) can depend upon  
components in Store or Services layer, but must not depend on or have  
knowledge of components in the JDBC layer.
The JDBC layer can depend upon components in any of the layers.

It seems that this was the original design anyway, although the rules  
for interaction may not have been stated explicitly.

In each layer, Derby has well-defined modules or components, with  
defined responsibilities. Roughly speaking, a module has an API, and  
an implementation.
At the module level, the rule should be that modules may interact  
with other modules only through the API, and not through any  
implementation details.
And of course, it is better that the API should be made up of  
interfaces, rather than classes.

Again, it seems to me that this is generally true in Derby, and is  
consistent with the original design.

While most of the Derby code is well-behaved with respect to the  
rules above, there are occasions when the inter-module dependencies  
appear unsatisfactory. Here is a sample:

1) The org.apache.derby.iapi.reference package contains constants  
that go across the boundaries of the layers. I can see the rationale  
behind having a central location for reference data, but would it be  
better from a modularity perspective, for each of the layers to have  
its own reference data?

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. 	

3) org.apache.derby.iapi.error.StandardException contains references  
to org.apache.derby.impl.jdbc.EmbedSQLException,  
StandardException also has knowledge about EmbedSQLException.

4) ShutdownException and ErrorStringBuilder are probably better  
placed in org.apache.derby.iapi.error, than in their present location  

I would like to submit patches to fix some of these and similar  
issues, but before doing so, would like to know if there are any  
violent objections to the general module interaction principles  
stated above.



View raw message