Comparing Node.js modules to an idiom in writing Java classes

On waking up this morning an idea was in my mind of a way to explain Node.js module structure & use by way of an idiom in writing Java classes.  Okay, I see that most JavaScript programmers go "ugh" whenever they think of Java, but it's a language I spent over 10 years living with as a Sun employee in the Java SE team, and it's an eminently useful language for certain realms of work.  And in any case this particular Java class idiom will make an aspect or two of Node.js modules a little more obvious than they are.

Most programmers are schooled in Object Oriented Programming and might find the Functional Programming model in JavaScript to be oddball.  They might also look at Node.js modules and expect them to behave as Objects.  But while JavaScript claims to be object oriented, it's only loosely so, and Node.js modules are not Objects.

The general structure of a Node.js module is

exports.funct1 = function(arg1, arg2) { ... }
exports.funct2 = function(arg1, arg2) { ... }
exports.funct3 = function(arg1, arg2) { ... }

Then to use the module you do this:

var mod = require('moduleName');
mod.funct1(val1, val2);

This is basic beginner stuff in Node.js, so you probably already know it.  In my book, Node Web Development, I had what still feels like a little bit of a stumble in explaining this.  What the Node.js runtime does is return the exports object from the require statement but Node.js doesn't make this explicitly obvious.

There's also a non-obvious encapsulation going on where the stuff that's global within the module isn't explicitly encapsulated within the module.  What I mean is the contents of a Node.js module is hidden within its own context and the "global" stuff inside a module is not visible outside the module unless it is assigned to the exports object, or it is returned by a module function.

In other words what I felt to be non-straightforward to explain are these two bits of non-obviousnesses. I'm not saying this is a major issue, or that I found it impossible to explain in my book, just that there are a couple non-obvious bits making the explanation a bit harder.

The idea I woke up with is a Java class paradigm that makes these things obvious:-

public class Module {
  public static class ReturnType func1(Type arg1, Type arg2) { .. }
  public static class ReturnType func2(Type arg1, Type arg2) { .. }
  private static Type localObj1 = ..;
  private static Type localFunct(Type arg1, Type arg2) { .. }
}

Then to use this class you write some code like this:

import package.Module;
... ReturnType res1 = Module.funct1(arg1, arg2); ...

This idiom, making the functions static, behaves like a Node.js module.  What it does is make a couple things explicit.  First, local functions and objects are explicitly marked as being private.  Second, because everything inside this class is contained within curly braces everything is clearly contained.