views:

31

answers:

2

I'm in the middle of building an application but found myself too easily creating new packages without keeping the project's structure in mind.

Now, I'm trying to redo the whole project structure on paper first. I am using a Settings class with public properties, accessed as settings for several other classes around the project.

Now, since this Settings class applies for the whole project, I am unsure if it should be packaged and if so, in what kind of package should it exist? Or should it be in the root (the default package) with the main application class?

I've been thinking about putting it in my utils package, then again I don't think it really is an utlity. Any strategies on how to decide on such package structure for example for a Settings class?

A: 

IMHO you should put it into a separate, low level package, since many other classes depend on it, but it (presumably) doesn't depend on anything. So it should definitely not be put in one package with the main application class. It could be in the utils package though, or in a separate package on the same level (e.g. config).

By "low level" I simply mean "low on the package dependency hierarchy", where a package A which depends on package B is higher than B. So it does not directly relate to the actual package hierarchy. The point is to avoid dependency cycles between your packages, so that you can have such an ordering between your packages.

Btw you should not use the root package in a real application.

Péter Török
+1  A: 

Use of the default package is discouraged anyway (in java it is actually enforced as a warning as far as I know), even for the class containing the main.

Other than that, I prefer having a config package, even if it's the only class in there. I don't think it would fit in the utils package.

laura
Is having a package with basically the same name as the only object it contains really encouraged? I thought packages are meant to group multiple classes together, so having only 1 class for a package doesn't seem right to me, maybe I'm wrong though?
Tom
Packages are meant to group classes together logically - if there's only one class with that particular purpose I don't see why not to leave it there alone. A `Settings` class is certainly not something to do with utilities for a project, it has to do with configuration. Another option you might be more comfortable with would be to put it to the top of the hierarchy, ie for a package `com.some_comp.some_software.<various_packages>`, the `Settings` would be on the same level with the `<various_packages>` part, at `com.some_comp.some_software.Settings`.
laura