Question

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?

Was it helpful?

Solution

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.

OTHER TIPS

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.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top