Skip to main content

(Not So) Stupid Questions 4: Assigning Packages

May 5, 2005


(Not So) Stupid Questions

Assigning Packages





Editor's note: Sometimes, the most interesting discussions begin when someone says, "This may be a stupid question, but ..." If the person asking the question has taken the time to think about the problem before asking, the question is often not stupid at all. Uncertainty points out an ambiguity in the specs, holes in the docs, or a search for how more experienced programmers might address a particular problem. From time to time, we will publish one of the "(Not So) Stupid Questions" we receive and invite our readers to answer the question in the feedback section.

Remember that new people are joining the Java community all the time and may be looking for help from those with more experience. Also, those who began with Java as their first language can benefit from those coming to the community with experience in other languages. As always, answer the questions with kindness. You are also welcome to submit your questions to .

This may be a stupid question, but ... "I have no idea when to create a new package and what should go in it."

First thoughts:

I have recently joined an open source project where all of their classes are in one single package that is more of a namespace than anything else. My first impulse is to suggest that they organize the project into packages and subpackages, but how do you decide what goes where? I've looked around for documents online, but most talk about packaging for deployment modules. I've looked at the java and javax packages to try to figure out what the recommended practices are.

Once you move some classes around and package them, you have to change accessibility and you might introduce dependencies. How do you balance organizing your project against introducing possible dependencies between packages? Is there a magic number of classes in a package that is too small to warrant a package, or too large to be a single package?

This brings me to three questions:

1. When do I introduce a new package?

2. How do I decide whether or not the package is a sibling to an existing package or a subpackage? and

3. When should a class be moved from one package to another?

(Not So) Stupid Questions is where we feature the questions you want to ask, but aren't sure how.

Related Topics >> Programming   |   

Comments

That's really a design issue

That's really a design issue of the api (or so I feel).

I've seen API's that put there core interfaces and implementations at the top level (com.something.api) and then use sub packages to store the concrete implementations. This makes browsing the API a little simpler.

I tend to try and break down my sub packages into working groups or concepts, but this will depend on the type of package I'm working on (library or application)

For me, it's about compartmentalization, grouping like elements into logic working groups (events/listeners come to mind) that help separate some of the complexity of the API and make it easier to navigate the source code over time.

A lot of the decisions will come down to personal preferences as well as consideration to the future developers. You want to make the "core" elements easy to find so people don't need to dig down a massive source tree to find things, while separating the logic elements to make it easier to conceptualize the overall design and intention of the API.