What is good practice for combining your classes

Question

Do not save all my classes in one src folder → 'package_name' I create different subpackages to separate my classes into groups such as utilities, models, actions themselves, etc. I'm not sure if this is good practice, and people do the same in real projects.

Answer 1

Yes, this is definitely standard practice for splitting your classes into packages. It’s good to establish an agreement on how they are separated to make things easier to find later. Two common approaches:

• Put things in packages based on what they are: model, service, data access (DAO), etc.
• Put things in packages based on the function that they support (e.g. java.io, java.security, etc.

I used both options and keep returning to the first because it is less subjective (it is always clear whether the class is a model or service, but it is not always clear whether it supports one function or another function).

Answer 2

Doing this by the type of class as you describe is one of the ways I've seen in real projects. I don’t care about it as much as before, because when I need to make changes or add a function, I usually need to have several packages expanded in my IDE. I prefer (when I have a choice) to group classes by attribute instead. This way, I know where to look for all classes that support this function.

Answer 3

The consensus I prefer is to first group the classes modulo, and then functional. For example, you might have the following structure:

com.example.modulea - modulea specific code that doesn't have any real need of a different package com.example.modulea.dao - data access for module a com.example.modulea.print - printing for module a 

...

 com.example.moduleb - moduleb specific code that doesn't have any real need of a different package com.example.moduleb.dao - data access for module b com.example.moduleb.print - printing for module b 

Thus, the code becomes understandable with the help of the package.

In a different style of grouping by pure functionality, the package size tends to be quite large. If your project contains 15 modules, and each module has one or more elements for each package, these are at least 15 classes per package. I prefer clearly separated packages than packages that simply group things, because "oh, here are some printing utilities that are used for each module, but only one module actually uses one of them from this package" - it just gets confused.