2012/3/18 Sébastien Brisard <sebastien.bris...@m4x.org>: > Hi, > I'm trying to clean up the SymmLQ class (see MATH-761 [1]). > The problem is the heart of the algorithm is very long (it would > probably amount to more thatn 600 lines). When I first implemented it, > I figured that I could split this algorithm in several methods: > init(), update(), updateNorms(), refine(), etc... This makes the code > somewhat more legible [2], with the difficulty that there is a lot of > data to be shared between these methods. That's the reason why I > created a simple nested, container class (namely, State) which holds > all the variables which are updated at each iteration. In order to > make checkstyle happy, all the fields of this nested class are > private, which means that a lot of accessors should be created with a > null benefit, since this class is nested anyway. I have to admit I > forgot to create these accessors, so synthetic accessors are > automatically generated at the present time. I'm not sure this is good > practice, but I'm also reluctant to implement all those (useless in my > view) accessors. So my question is two fold > > 1. Would it be acceptable to have public fields in a nested class? If > yes, the checkstyle rules should be modified. > 2. Is it good practice otherwise to let the JVM generate synthetic > accessors (which would probably get inlined anyway by modern JVMs?).
Why not put the methods and the data in the same class? That would eliminate the need for accessors. > I'm currently puzzled by the SymmLQ class. I feel the need for some > cleaning up, but I do not really know where to start. So if anyone > feels like reviewing the code, I would be grateful for some help. The > good news is that unit tests are very extensive, so we can try drastic > refactoring. > > Thanks for your help! > Sébastien > > [1] Which is probably ill-named. Should be named "cleaning-up SymmLQ" > [2] I have to say I have mixed feelings now: I'm wondering whether a > 600-hundred lines method would not be better in that case, but I would > probably not get a wide support... > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
