db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel John Debrunner <...@apache.org>
Subject Re: Reducing module dependencies
Date Tue, 12 Feb 2008 05:45:06 GMT
Dibyendu Majumdar wrote:

> On 11 Feb 2008, at 21:56, Daniel John Debrunner wrote:

>> I guess I don't quite see what the issue is with a "shared interface 
>> that defines all [related] constants." These are compile time only 
>> artifacts as they only contain literal constants.
>> I agree that in some cases it may make sense to move specific classes 
>> from a central reference area to a more specific are, e.g. jdbc 
>> constants could move to o.a.d.iapi.jdbc, but doing so is not improving 
>> the modularity of Derby, it's just a preference of location.
> Well, it depends upon how you view modularity, encapsulation, etc..
> The problem with a shared interface that mixes information from multiple 
> layers, or modules, is that it breaks the basic component interaction 
> rules. It breaks the basic principle of information hiding.

I agree with the principle of modularity, especially having a clean api 
and hiding information, but here the shared information is property 
keys, attribute names, sql states (exception ids), stored format ids.

I'm just also concerned about the effect on the codebase for developers, 
especially newcomers. Is moving the SQL states into 50-70 separate files 
(number of module api & implementations) an improvement to the clarity 
of the code? Most likely it will be hard to tell until a patch appears 
and people can judge how the code looks.

> The consequence can be that this information is misused. 

Exactly, "can be", but how likely given the type of information being 
shared here?

> For instance, 
> at present, what is to stop a Services layer module to have a dependency 
> on some constant that is defined in a higher level module?

Not much, but I don't think any scheme will stop that. If the coder 
thought that the function was appropriate then they will code it no 
matter what. If the constant they need is not available (e.g. not 
public), then they will simply make a local definition of it.

There's a patch out there for Derby which creates a new service level 
api and it includes an implementation class (o.a.d.*.impl.*) from a 
higher level module. So all the code was correctly laid out, but still 
the modularity would be broken.

It's more creating an understanding of modularity.


View raw message