On 17/03/2009, Christian Grobmeier <grobme...@gmail.com> wrote: > Hi all, > > just made a quick fix for SANDBOX-284: > https://issues.apache.org/jira/browse/SANDBOX-284 > > I could not test it with a general working testcase, since this is a > platform problem and i have only OSX. > However, GUMP will not run on windows too, i guess. I think here is > some refactoring necessary to make > this code more testable.
Not sure what Gump has to do with this. > Before I do this, this brings me to a question of codestyle. I prefer > to do quite less in the constructor. TarArchiveEntry does quite much, > and i think this is necessary in this case. The other option would be > to construct it empty and do all that stuff in a setter, which would > bring no benefit. To make it testable, I would have to extract some > methods from the constructor. Normally I would mark them private, but > private methods cannot be tested, except with reflection. > > My question is, is it common use at commons to test with reflection in > that special and rare cases? Or should I mark the package scoped, just > for the sake of testability? Constructors should not generally call overridable methods, as these can cause problems if the class is ever extended. So make any such methods final. Also, any instance fields that are mutable mean that synch. is likely to be needed to ensure that the class is thread-safe. Immutable classes are always thread-safe, and easier to test because they only have one state. However, if the class is not intended to be thread-safe, then of course the mutable fields are not a problem. > I think I would prefer option one, even when it reminds me on the > story with cannonballs and that birds. > > Cheers, > Christian > > --------------------------------------------------------------------- > 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
