Re: Coding standard for inner-class like features ?

[Jason van Zyl]

We'll be following OSGi standards as ultimately Maven will run in an  
OSGi runtime. So whatever best practices are there we will follow as  
far as package structure.

On 2009-11-16, at 9:16 AM, Kristian Rosenvold wrote:

I'm trying to make some further adjustments to the concurrency  
features
proposed to MNG-3004. I have read all the faq's and the
maven coding standard. This is probably an old can of worms, so I'll  
try to
keep this question simple:

It seems to me like the predominant standard for inner classes in  
what I've
seen of the code base is the "hide everything approach"
with private inner classes. While a great strategy in the  
information hiding
department, it is a suboptimal strategy in the unit-testing
perspective since it basically forces you to test the class as a  
whole. It
also has a tendency to create extremely large class files
(DefaultLifeCycleExecutor which I'm looking at now has 2100 lines or  
so).
Testing 2100 lines of code through only a few front-facing methods  
is really
cumbersome and usually misses out quite a few of the interesting  
details.
It's like trying to take portait photos through satelite imagery.

I know there are several ways of achieving this, with different  
kinds of
strengths/weaknesses. Personally I tend to favour the "internal"  
subpackage
(e.g. org.apache.maven.lifecycle.internal), because it avoids  
polluting the
namespace of your public artifacts with non-public stuff (and  
strictly, the
inner class X when exposed through class Y becomes part of the api  
for Y).
Package level protection for the test-exposed stuff is also nice,  
better
than "protected/subclassing".

Is there any consensus on how this should be done to get unit- 
testability?
Maybe something could be written in the coding standard ?

Kristian Rosenvold

Thanks,

Jason

----------------------------------------------------------
Jason van Zyl
Founder,  Apache Maven
http://twitter.com/jvanzyl
----------------------------------------------------------


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org