I may try a round of refactoring this night if you'd like. The intent of making the models private is to restrict their external use/visibility. So that for someone outside the SPI are the methods used during the lifecycle of constructing the model. By making the models private you make them part of the internal state of the collection type. * I looked a bit more detailed on the code and by now most model types are just used by their collection types "XxxsModel". Except: * MixinModel (1 outside usage) * InjectionParameterModel (2x creational blocks that could be extracted to an "add" method on InjectionsModel) * ParameterModel (heaviliy used outside in creational code)
I'll try to refactor these and send you the diff. It was just an idea as it seemed natural. It would also reduce the number of visible classes. * Static Factory methods that are used only internally when constructing the model set (if needed at all). Rickard Öberg wrote: > 2008/5/29 Michael Hunger<[EMAIL PROTECTED]>: >> 1) Why do you still publish most of the internal state of the models via >> accessor methods? Is there real need for that? >> I thought reverting to the real "business" methods on the model removes the >> need of publishing the internal state of the >> models. > > Why? Because I haven't come up with a way not to. If you can, feel > free to point out how. I *have* removed a lot of internal state > access, and replaced it with business methods, but there is certainly > room for more such improvements. > >> 2) What do you think about taking the model classes for instance >> ParameterModel (or CompositeMethodModel) and making it >> an private inner class of the "composite" collection type ParametersModel >> (or CompositeMethodsModel) allowing acces to >> it only through the collection type (including the creation/addition). >> Creation of the collection type perhaps via a >> static factory method. > > In general I'm not a big fan of static methods, and I'm especially > curious about how that would work in an OSGi environment, which is > something we will aim for in the end. It would be a good thing to > avoid statics as much as possible I think. As for making some of these > models private, well, why? Making them package protected might be a > good start, but right now I'm not sure whether that will work out in > the end, so I went with public. Again, it's more to do with me not > figuring out how to do it than anything else. > > /Rickard > > _______________________________________________ > qi4j-dev mailing list > [email protected] > http://lists.ops4j.org/mailman/listinfo/qi4j-dev -- Michael Hunger Independent Consultant Web: http://www.jexp.de Email: [EMAIL PROTECTED] Enthusiastic Evangelist for Better Software Development We support Software Engineering Radio (www.se-radio.net) _______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
