Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <h2>The short answer:</h2> <p>Use packages when your project <strong>requires a specific organization or hierarchy</strong> to it, or when <strong>your framework disallows the use</strong> of the default package. For simple CS projects, it can be overkill.</p> <h2>The longer answer:</h2> <p>Packages are folders recognized by Java that allow you certain perks:</p> <ul> <li><p>You can have two classes that are named the same that live in different folders, without causing conflicts.</p> <p>A common example is <code>java.util.Date</code> and <code>java.sql.Date</code>; depending on what you're doing, you may wind up using <em>both</em>. If you do, you'd have to use the <a href="http://en.wikipedia.org/wiki/Fully_qualified_name">fully qualified class name</a>, which is like writing <code>java.util.Date date = new java.util.Date();</code>.</p></li> <li><p>You give your project a sense of hierarchy and organization; giving each class a sensible place to "live".</p></li> <li>Classes that have package-private methods and/or fields will not be accessible across package boundaries, which can be desirable in certain cases.</li> </ul> <hr> <p>Take, for example, my current project. I have decided to write a metadata parser that will read MP3, FLAC, Vorbis, and AAC files.</p> <p>Right away, I have four common interfaces:</p> <pre><code>MP3 FLAC Vorbis AAC </code></pre> <p>...however, these are all really compression formats (and FLAC is lossless, so there's no compression there), so they belong in a place that conveys that.</p> <pre><code>name.makoto.format - MP3 - FLAC - Vorbis - AAC </code></pre> <p>That's all good and dandy. But where would the class that actually does the parsing live? What if it lived in a reader package?</p> <pre><code>name.makoto - reader MediaReader - format MP3 FLAC Vorbis AAC </code></pre> <p>Suppose now I want to implement those format interfaces. Doesn't make sense to have them living at the same level as the interfaces themselves, since those are just an API into what the actual object will be anyway. Let's move that to an <code>impl</code> package.</p> <pre><code>name.makoto - reader MediaReader - format MP3 FLAC Vorbis AAC - impl MP3Impl FLACImpl VorbisImpl AACImpl </code></pre> <p>I'd go on, but it gets kind of crazy from here.</p> <p>What I have here is a sense of hierarchy and structure to my project. It's a sizable project, so I could benefit from the organization.</p>
    singulars
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
    1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload