I just looked through the schema packages and noticed that it has
become another hives nest of inter-dependency. I'm not blaming anyone
here so please don't get the wrong idea. I just want to avoid these
trends because they cause more complexity and lead more unnecessary
work. Let me show y'all some code to be clear.
There once were clean simple schema entity interfaces like
AttributeType that were used to shield the API from getting
contaminated by irrelevant implementation methods and functionality.
 shows an example of a clean interface which was there earlier that
most of the code handled. This was removed and replaced by a class.
Now look here  to see the big 1800 line file mixed with all sorts
of functionality  like addToRegistries(). This method has no place
in this object which is now used globally. As a result,
interdependencies have increased through and through inside these
packages as well as in the server which now depends on these out of
place methods. It's going to be a PITA to clean this up and the work
will be twice, maybe more, as hard as when the interfaces were
removed. The rest of the code base now has come to depend on these
non-essential methods specific to some function or use case associated
with implementation details.
I'm trying to get some traction with making schema loadable and this
is yet another surprise to have to contend with. Please let's not
remove interfaces just because they seem unappealing. When in doubt,
leave the interface where it is, it can't hurt, but the opposite can
hurt a lot. I'm sitting here starring at this nest and wondering what
the heck I should do first.
 - http://goo.gl/2j5dT
 - http://goo.gl/G7wBV