Hi Alex, That's something I had also noticed a few weeks ago. See [1].
I wanted to decouple the SchemaObjects from the SchemaManager, but I guess I ran into other work and couldn't complete it. AFAIR there are around 5 methods in the SchemaObject interface/abstract class that needed to be removed and added in the SchemaManager utilities. I'm not sure they are that much used outside of SchemaManager related classes. On the lack of interfaces for schema objects, it's probably a little more complex to move them back and requires more refactoring from depending parts. Tell me if I can be of any help about those two matters. Regards, Pierre-Arnaud [1] - http://directory.markmail.org/thread/mq2yerlo7b7dcd4m On 8 mars 2011, at 00:09, Alex Karasulu wrote: > Hi all, > > 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. > [0] 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 [1] to see the big 1800 line file mixed with all sorts > of functionality [1] 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. > > Best Regards, > Alex > > [0] - http://goo.gl/2j5dT > [1] - http://goo.gl/G7wBV
