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
