What are the steps needed to be taken to group related classes into packages in Java?

In my case, I have about a number of .java files that I'd like to group into 3 packages according to the MVC pattern. One package for Model classes, one package for View classes and one package for Controller classes. I've identified which belong in what package, but not sure of the next step.

I want to know how to seperate them into packages, do I make 3 folders and place the .java files in the folder that represents the package they belong in?

  • 1
    Are you asking how to do it (answer: include package declarations and move the .java files around in the file system), how to decide what packages to create, or how to decide which class goes where? Commented Nov 7, 2013 at 8:21
  • I want to know how to seperate them into packages, do I make 3 folders and place the .java files in the folder that represents the package they belong in?
    – Dawson
    Commented Nov 7, 2013 at 8:25
  • related (possibly a duplicate): How to divide OO project into packages?
    – gnat
    Commented May 29, 2014 at 14:16

3 Answers 3


Java requires that the name of a class file reflects the class name but there's no such requirement for packages. Packages are just names that do not form hierarchies although it might appear so on the surface. It is still a good practice to separate different packages to different directories that reflect the package name. All development environment do this for you automatically.


Sun / Oracle Java coding conventions abstain of providing concrete requirements on how to package.

Per my reading of related parts of conventions, this appears a deliberate decision: developers are expected to package at their discretion, following the general guidance and ideas provided by conventions.

Particular convention to keep in mind is 10.1 Providing Access to Instance and Class Variables

Don't make any instance or class variable public without good reason. Often, instance variables don't need to be explicitly set or gotten-often that happens as a side effect of method calls.

Take into account that classes and methods referred from within the same package allow to avoid public access, this gives sort of a preference to larger packages.

But, if one follows above blindly, this may lead to unmantainable packages that are too large. To balance for that, one would better take into account the part of 3.1.3 Class and Interface Declarations that gives guidance on how to group things (bold font in below quote is mine):

...methods should be grouped by functionality rather than by scope or accessibility... The goal is to make reading and understanding the code easier.

You see, as soon as you feel (better yet, find in ) like package becomes somehow difficult to read and understand, it's time to reconsider the packaging ("grouping"), following above considerations.

Use your judgement, tests and code reviews to keep code readable and maintainable, and avoid using public without good reason - that's it.

Applied to your case, above means you are not strictly mandated to make three packages as you listed. For the reference, Martin Fowler gives strong recommendation to only separating the model:

Make a strong separation between presentation (view & controller) and domain (model) - Separated Presentation...

For view and controller, Fowler still recommends some degree of separation, but not in such strong terms:

Controller and view should (mostly) not communicate directly but through the model.

I have even seen a pretty compelling reasoning in favor of keeping controller and view close to each other:

...a view and controller are often intertwined - think of it as M(VC).

The controller is the input mechanism of the user interface, which is often tangled up in the view, particularly with GUIs. Nevertheless, view is output and controller is input. A view can often work without a corresponding controller, but a controller is usually far less useful without a view. User-friendly controllers use the view to interpret the user's input in a more meaningful, intuitive fashion. This is what it makes it hard separate the controller concept from the view.

Think of an radio-controlled robot on a detection field in a sealed box as the model...

Most user-friendly UI's coordinate the view with the controller to provide a more intuitive user interface. For example, imagine a view/controller with a touch-screen showing the robot's current position in 2-D and allows the user to touch the point on the screen that just happens to be in front of the robot. The controller needs details about the view, e.g. the position and scale of the viewport, and the pixel position of the spot touched relative to the pixel position of the robot on the screen) to interpret this correctly (unlike the guy locked in the closet with the radio controller)...

With above in mind, you have a reasonable option to start designing your code split to two packages instead of three (say, model and, if you prefer to follow Fowler's naming, presentation).

Further down the road, as you add more code, you need to keep an eye on keeping the code good for "reading and understanding", as suggested by Java coding conventions quoted above. Writing tests and going through code reviews provide good means for such a "complexity monitoring".

If you find that particular package becomes troublesome in that regard, consider splitting it or extracting some part of it into a new, separate package. It can happen that this will lead to splitting presentation package to view and controller, bringing it to exact match with MVC, but one can't tell beforehand whether it will be the case or not.


I like to organize my packages using the same technique I use to evaluate cohesion in a class: think back to Sesame Street! "One of these things is not like the others..." :)

It may seem silly or even flippant, but it works surprisingly well. Once you start thinking about ways where things are the same or different, it gives a good context for deciding how to organize. There usually isn't a "right" way to do it, but java (and a number of other languages) are flexible enough that it doesn't matter too much.

With packages specifically, I also ask myself how many import statements will be needed by clients of the module/library I'm writing (both with or without using * wildcards).

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.