• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Devaka Cooray
  • Liutauras Vilda
  • Jeanne Boyarsky
  • Bear Bibeault
Sheriffs:
  • Paul Clapham
  • Knute Snortum
  • Rob Spoor
Saloon Keepers:
  • Tim Moores
  • Ron McLeod
  • Piet Souris
  • Stephan van Hulst
  • Carey Brown
Bartenders:
  • Tim Holloway
  • Frits Walraven
  • Ganesh Patekar

Is there a point to creating more than two levels of packages?

 
Greenhorn
Posts: 14
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I am trying to learn how to organize my java projects better.

Generally my projects have a source package, and multiple packages one level below that source package that I keep all my classes in.

I know that when creating a new class file, the outer class's it contains must be either public, or package-private.

This confuses me because it seems like there's little point to creating packages within other non-source packages if the classes on different package-levels cannot access each other without also being accessible anywhere.

It seems like there should be a way to allow classes to be accessible to the other classes in the same package and the package above it without the class also being accessible everywhere.

I know people will create more than two levels of packages, but I don't understand the point unless it's just to make the file structure look neater.

Why do people create more than two levels of packages in their java programs?
 
Saloon Keeper
Posts: 10434
223
  • Likes 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You've already identified that there is no technical reason to do so. "Nested" and "enclosing" packages have no more or less access to each other than completely unrelated packages.

The reason to make deeper levels is because the packages are related to each other semantically, and we like to organize our lives.

I usually have a base package where I put my core model files. For instance, there might be a class com.example.chess.ChessPiece. If I wish to save program state somewhere, I could have an interface com.example.chess.persistence.ChessRepository. I could implement my persistence layer in various ways. For instance, I might want to save state to a file system, or to a relational database with JDBC. So I could have a class com.example.chess.persistence.jdbc.JdbcChessRepository. There's also the presentation layer, where I could have a class com.example.chess.presentation.swing.ChessBoardPanel.

As you can see, there is a logical structure to nesting the packages. There is no single right approach however. You do what makes sense to you and your team mates.
 
Marshal
Posts: 67275
170
Mac Mac OS X IntelliJ IDE jQuery Java
  • Likes 3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Most of my Java projects have had thousands of classes. It needs more than two levels to keep that organized.
 
Phil Patterson
Greenhorn
Posts: 14
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Bear Bibeault wrote:Most of my Java projects have had thousands of classes. It needs more than two levels to keep that organized.



Do you make most classes public or try to make as many package-private classes as possible to support public ones? I guess you just use public classes even if they're only used in one package other than their own?

I am trying to go with a design where each package holds one main public class that allow communication between everything else and several supporter package-private classes that handle most of the actual logic. I divide the packages by roles, but sometimes one particular part of a role is very complex, and I feel like I want a special inner package just for it. There are several things I could do, put everything in a single huge class file, make multiple class files and just have them reside in the same package with everything else, maybe name them something that will indicate they all handle that one aspect of the role. What's usually the best option in that case?
 
Bartender
Posts: 20940
127
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You might want to take a look at how open-source package libraries are organized.

Often they will have a base package(es) containing the public interfaces and/or base classes, then subpackages for the different subsystems in the library.

Something worth noting as well is that the most common way to control logging from a product is by selecting what package subtrees you want for a given logger/loglevel. So there's an incentive to put stuff that needs controllable diagnostics together which separating out the stuff that would spew more trivial messages.
 
Stephan van Hulst
Saloon Keeper
Posts: 10434
223
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Phil Patterson wrote:I guess you just use public classes even if they're only used in one package other than their own?


Probably not. This is a bad idea. Only make classes public when you *definitely* need to use them outside of their package.

I am trying to go with a design where each package holds one main public class that allow communication between everything else and several supporter package-private classes that handle most of the actual logic.


This doesn't sound right. It seems like you're trying to force your application in a form that might not be natural. The primary concern is to make your classes responsible for solving logical problems, not for organizing your application. Then, group related classes together. If they need to know relatively much of each other, or they just "feel" like they fit together, you probably want to put them in the same package. Then, if you need to use them in a different package, either make them public or expose their members through a public interface. Typically, classes that represent a 'value' can be made public directly. Classes that represent a 'service' should be exposed through an interface. When you have such a collection of public value types and service interfaces, your "one main public class" becomes unnecessary.

sometimes one particular part of a role is very complex, and I feel like I want a special inner package just for it. There are several things I could do, put everything in a single huge class file, make multiple class files and just have them reside in the same package with everything else, maybe name them something that will indicate they all handle that one aspect of the role. What's usually the best option in that case?


Like everything, it depends. If a particular aspect is so complex that it requires more than two or three classes to implement, you might want to put it in a separate package. Another reason to put classes in a separate package is because, even if they are closely related to the classes they're depending on, you want to force them to only use the publicly exposed methods of their dependencies. An example of the latter:


So how does one get an instance of DeepBlueStrategy? We could make the class public, but this is an example of a class that just acts as an implementation for a service interface, so a good alternative is to make a static factory class:

Maybe this is what you mean by "one main public class", but it's definitely not a good idea to pursue this approach with no regards to what's natural for a particular collection of classes.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!