Java "module" size

Question

Is it sensible to have micro-modules, say with only a very few (perhaps one) class in it? Or should I store things in bigger repositories?

I am long-time Java developer with a software-engineering background. I try and write well encapsulated, focussed OO code. I have previously written code in large modules/projects/repositories with main module depending upon "common" modules.

"Common" modules seem to be a code-smell in the same way as common/util classes - a sign that someone hasn't thought what the real, clean encapsulation is.

I am now wanting to publish some articles on a blog and back them up with code on BitBucket, with 1 article with its own module & repository.

I like clean dependencies, hate duplication, etc and there are natural downward dependencies from 1 module to "common" code.

Java doesn't make dependency management very easy (hopefully fixed in Java 9 with Jigsaw), but interestingly Google Dart has a very nice mechanism and seems to recommend small, tight modules (and presumably repository per module).

I'm thinking of small modules of Java, with Maven dependencies. Each module in its own repository. Jar's published on some maven site.

EDIT: 1) I want to write some blog posts. Each post will be about a different topic. Each topic will relate to a cohesive module of code. I want readers to be able to download the module of code for the post.

2) I am using Bitbucket as my git repository. Point 1) implies (?) that I need a repository per module/blog article.

3) I'm trying to do things reasonably correctly: don't need perfection

4) Blog articles are only part of it: I want a good decomposition into modules for sound software engineering reasons.

5) I'm not ready to make my repositories public yet, they are incomplete, but these are the modules I currently plan: - 5a) Validation - just a single class with useful validation (I like DbC-like stuff!) 5b) HTML generator - nice module to generate HTML from Java - depends on Validation 5c) Swing "panning" component - again depends on Validation

6) Each of the modules in 5) depend upon Validation and are also discrete modules.

So, should I have 6a) 3 x repositories (allowing people to easily pick and mix) 6b) 1 x repository building a single jar 6c) 1 x repository building 3 x jar, 1 per "module"

Answer 1

When I think of Java I tend to think in packages, not "modules", but I guess I'm too back-end/API oriented. Modules are front-end/use-case oriented and should be mostly in the view/controles layer.

In the business logic/model layer you should not worry about "module" size, since classes, interfaces etc, would be in packages.

In the presentation/view-controller you can think of "module" size, but then it's not clear what can be considered "large". For me, large is about lines of code, not number of classes. What worry me is the size of classes, not the number of them.

The size of a module is mainly dictated by the use-cases and the features the application will have. Do you feel a given screen is doing too much ?

In conclusion, if you are doing object oriented design well, you should not worry about number of class. Worry about classes having too many lines of code or screens/applications doing too much.

EDIT: I'm really meaning encapsulation of larger ideas than a single class, and re-use of code across multiple projects.

An example package could be a Swing dialog box which has one main public class that client-code should use and any number of implementation classes which client code should not see. Java makes this difficult (until Jigsaw). Should this package be a module (own jar) if its shared over projects, or should they all be bundled up into a large "shared-dialogs" project?