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 22:16:50 GMT

On 11 Feb 2008, at 21:56, Daniel John Debrunner wrote:
> 1) To me this seems to be making something simple much more complex  
> for no real benefit. It's good if open source code is easy to  
> understand and follows existing practices. Java defines constants  
> as static final fields in interfaces or classes, e.g.
>
>   public static final String JMX = "derby.system.jmx";
>
Agreed, it is more complex.

>
> 2) Such constants would probably no-longer be in-lined by the java  
> compiler, leading to potentially slower code as a field lookup is  
> needed.

Not sure about this, as a final value should be in-lined regardless  
of how it is initialized. But this can be tested, I suppose.

> 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.
The consequence can be that this information is misused. 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?

It might look like I am taking a purist view just for the sake of it,  
but I don't think so. It makes life easier if less information is  
shared. It makes it easier for some component to be replaced. Even a  
very simple example will illustrate - just the fact that some  
information is shared, means that I have to carry out an expensive  
impact analysis, which I could have avoided. So I think that the  
benefit is real.

Regards

Dibyendu




Mime
View raw message