• 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 Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

package organization conventions

 
Ranch Hand
Posts: 49
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi all,

I always feel stupid when I create a new class and I wonder in which package I should set it. So I was wondering if there were any conventions (beside the obvious <domain>.<company>.<project> prefix) regarding package structures.

I do have some conventions I use:

.domain for POJO
.controller for controllers (duh)
.service for interfaces

but then I have all the things like utility classes, implementations of my interfaces, comparators, data access layer etc... I guess there must be a default package architecture where anybody would find his way, but what would that be? How do YOU organize your classes?
 
author
Posts: 3285
13
Mac OS X Eclipse IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
This is one of those questions that will raise a thousand different answers

My answer is: It depends on what your project is!

sandard ones I tend to use are

* util (For any utility classes, some people like to have one big util package, others have util packages at various levels)
* persistence (for the data access layer and other persistence)
* domain (for 'business' domain objects)
* security (for any security specific classes)
* plugins (self-explanatory)
* management (for any management interfaces/code I might build)

At the end of the day how you cut and slice it will be dependent on what you're building. You'll also often find that you'll want to restructure your packages later on, a good refactoring tool makes this fairly trivial.
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic