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.
Dan.
