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"

  • When you write "modules", I think of modules as being source-files like modules are in Python. Will you provide a link to the modules that you are referring to? Another answerer wrote that perhaps that you are referring to .jar files when you wrote "module". Please clarify. (I use Java 6 and Java 7, I haven't really looked at Java 8 and Java 9).
    – Kaydell
    Oct 10, 2013 at 11:55
  • When you use the term "repository", I think of version control repositories such as storing source code in a repository on bitbucket.com. You wrote about "modules/projects/repositories". Will you give us some links for us to more easily understand your terminology?
    – Kaydell
    Oct 10, 2013 at 11:57
  • I sounds like you are using very state-of-the-art technologies. Although I don't understand exactly what you're talking about, I do know that if you try to develop the "perfect solution", that you can get "writer's cramp". Sometimes, you should just go for it and get things done and you can always refactor your solution or rewrite it and do a new, improved version later.
    – Kaydell
    Oct 10, 2013 at 12:01

1 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?

  • I'm really meaning encapsulation of larger ideas than a single class, and re-use of code across multiple projects. I'm completely aware of java packages and also server- and client-side (Swing) development.
    – David Kerr
    Oct 9, 2013 at 12:39
  • 1
    I think OP is thinking in terms of JARs when they are talking about modules... Oct 9, 2013 at 13:52

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.