-1

this might seem like a dumb question to some, but bear with me please.

  1. I understand that when a project is large or massive with multiple similar classes for e.g. Data Access Objects and Services etc, it is helpful for the developers if these classes are organized in their own packages, for easier visualization of the project structure, as well as keeping a neat organized state of the project.

  2. Protected classes can only be accessed by those classes in the same package, giving some security to the accessibility of those classes.

Finally my question is, is there any other reason than those mentioned above, why one should have different packages in the project? When talking about smaller projects, which can have fewer classes and simpler functionalities, will packaging classes in similar fashion as is usually done in larger project structures give any additional benefits?

Jonathan Hall
  • 75,165
  • 16
  • 143
  • 189
ghoulfolk
  • 326
  • 7
  • 17
  • 1
    This question is asking for opinions. This is not the most appropriate place to ask such questions. – Brett Walker May 06 '15 at 06:52
  • For small project a single package is enough. – Tagir Valeev May 06 '15 at 06:55
  • Why bother splitting your code across multiple source files? – Andy Turner May 06 '15 at 07:02
  • My intention was not to ask for opinions about packaging in a project structure, but to get to know more about the possible efficiency, speed, security and other benefits that packaging can have an impact on within the project, other than those which I had already stated to understand. Thank you all who enlightened me on the matter. – ghoulfolk May 06 '15 at 07:18
  • Isn't clarity for the developers the most important thing? It leads to maintainability. We could all be writing assembly code if clarity for the developers wasn't important. – Erwin Bolwidt May 06 '15 at 07:19

3 Answers3

4

Breaking down a project into smaller modules (packages) makes the product more organized, thus make it easier to maintain.

Other than maintenance, packaging, if done right (that is, you do not throw in packages just for the sake of having them), should reduce coupling of your code, but make it work well the other modules. This should, in turn, make it easier to re-use your code.

With regards to smaller projects, I would still recommend breaking it down into other packages where needed. Smaller projects might end up being big ones, so having a basic structure already in place eases development, and the developer can focus on the things they need to do, rather than how to restructure the entire thing.

npinti
  • 51,780
  • 5
  • 72
  • 96
  • This makes a valid point on never knowing how large the project will become in the future. Thanks for the answer – ghoulfolk May 06 '15 at 07:08
1

  • You can have classes with the same name under different packages. You can't do that if classes are under a same package.

  • Your project has a well defined organized structure, say in future you wan't to change the implementation for the service layer as it is under a different package, it makes the maintenance of the app easier. It makes your app more loosely coupled.

Even if you have fewer classes in a smaller project you should keep the classes under different packages as per the module.

Check this out

Community
  • 1
  • 1
underdog
  • 4,447
  • 9
  • 44
  • 89
1

If you have a large project and need to make a small change to it, it can be time consuming to recompile the entire project. Separating it into manageable pieces that are easier to understand can make compile time much quicker since you only need to recompile dependencies that have been alternated.