On this point it is mostly a matter personal opinion unfortunately,
and not worth changing if you prefer your structure. I see some old
code in the project that follows this structure, yes. I have, I think,
good reasons for preferring the structure I suggest, so I'll give them
here for fun.

(Static) inner classes behave like any other top-level class, at
heart, so in a sense there's no point in fussing over using one over
the other, right? I take an opposite view: we have this separate
syntax available in Java, so why not find style / design reasons to
prefer a static inner class over any other top-level class? or else
it's like tossing a minor language feature out the window.

Static inner classes are, spiritually, more similar to non-static
inner classes than top-level classes. And of course non-static inner
classes are used in a very specific circumstance -- when an instance
of an inner class only makes any sense in the context of the existence
of an instance of the outer class.

I think static inner classes should share some of this reason for
being. A class should be an inner class, static or no, when its
purpose and existence is intimately bound with that of the enclosing
class. Otherwise it should be a top-level class by default.

And Mappers and Reducers are quite stand-alone concepts, even if they
are closely related to each other and to some "Job" class. This is
what the powers that be gave us packages, and package scope, in my
opinion, rather than inner classes.

I stand by the reasoning, and continue to use it, and I think it is
the dominant paradigm in Java coding in general and this project in
particular. But, even as much as I take a "broken windows" attitude
towards coding (getting the little things right creates and
environment where people get big things right) I can't say this is a
big deal so don't bother changing anything.



> Sorry, not to start a discussion on this or anything, but just for my 
> information, is this is project-wide consensus or it is your opinion? I don't 
> think i am with you on this, nor do i think i see consensus in the project. I 
> did not scan all the Mahout tree for this but just scanning one package up, 
> all the DRM jobs seem to be happily use inner classes. At least it seems 
> there wasn't such consensus until pretty recently. Hadoop literature that i 
> scanned seems to use inner classes too.
> {quote}
>
> I typically prefer inner classes for mappers and reducers as long as they are 
> static.  I have no problem finding them since IntelliJ hunts them down 
> instantly.  It is a bit of a pain from vi.  From emails etags will find inner 
> classes as easily as anything.

Reply via email to