Michael Hunger wrote: > yes, the problem is the separation of the modules and which code belongs > where (cyclic package/module dependencies). But loading a single Factory > class with that many specific methods doesn't seem right either. Perhaps > moving the Model-Creation methods to a separate entity would help.
Yes, in general the creation of Models should be extracted into Factories. We have started it, but we should always be striving to having more of it. > What do you think about these Helper/Utils classes like AnnotationUtils? > I don't like repeated code as the problem of keeping it all in sync > should not be underestimated. Very true. There is a org.qi4j.runtime.util package, and I don't mind putting things like the getAnnotationsForType method in there. > Besides using create Factory Methods > instead of constructors gives you a lot more freedom of the > implementation and of the readable naming of the method. Agree. > I looked at the usages of ParameterModel and most of the usages are in a > form of Collection, List, Iterable<ParameterModel> I'd like to refactor > it to a separate entity named ParameterModels (although the readability > of this name .i.e. difference between ParameterModel and > ParameterModel_s_ is quite bad)). Right now there are a lot of methods in the models that return collections, and my suspicion is that some of the operations performed on those collections should be pushed into the models themselves. This comes back to the problem of "object as container of stuff" vs "object with methods that does stuff". If possible I'd like to promote the latter, and I am aware of that currently many of the model classes are of the former kind. > What about the general usage of the final modifier? > I'd like to use it for immutable instance fields, parameters and local > variables. Not only it helps to escape typing errors when assigning the > variable twice. It also documents the immutability of the target. Both Niclas and I very much agree with this, and anytime a final modifier has not been used and it should be, is considered a bug. > And it supports a more functional style of command/query separation. > > What about java-doc documenting the SPI-classes? (I'd do it for the > AbstractModelFactory). Right, I did a run some time ago to document the API, and the SPI is up next. There are still some violent refactorings I'd like to do in the SPI, the implementations anyway, but things like the EntityStore/EntityState definitely should have more docs, just so we can help determine exactly what their responsibilities are (and aren't). /Rickard _______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
