322

Often, in libraries especially, packages contains classes that are organized around a single concept. Examples: xml, sql, user, config, db. I think we all feel pretty naturally that these packages are correct in the singular.

com.myproject.xml.Element
com.myproject.sql.Connection
com.myproject.user.User
com.myproject.user.UserFactory

However, if I have a package that actually contains a collection of implementations of a single type - such as tasks, rules, handlers, models, etc., which is preferable?

com.myproject.tasks.TakeOutGarbageTask
com.myproject.tasks.DoTheDishesTask
com.myproject.tasks.PaintTheHouseTask

or

com.myproject.task.TakeOutGarbageTask
com.myproject.task.DoTheDishesTask
com.myproject.task.PaintTheHouseTask

0

4 Answers 4

422

Use the plural for packages with homogeneous contents and the singular for packages with heterogeneous contents.

A class is similar to a database relation. A database relation should be named in the singular as its records are considered to be instances of the relation. The function of a relation is to compose a complex record from simple data.

A package, on the other hand, is not a data abstraction. It assists with organization of code and resolution of naming conflicts. If a package is named in the singular, it doesn't mean that each member of the package is an instance of the package; it contains related but heterogeneous concepts. If it is named in the plural (as they often are), I would expect that the package contains homogeneous concepts.

For example, a type should be named TaskCollection instead of TasksCollection, as it is a collection containing instances of a Task. A package named com.myproject.task does not mean that each contained class is an instance of a task. There might be a TaskHandler, a TaskFactory, etc. A package named com.myproject.tasks, however, would contain different types that are all tasks: TakeOutGarbageTask, DoTheDishesTask, etc.

9
  • 16
    For a similar question, see english.stackexchange.com/q/25713. A category is analogous to the singular and a type is analogous to the plural. May 17, 2011 at 15:11
  • 7
    The very link you provided shows an exception to this rule. beans is plural, however java.beans contains all kind classes related to JavaBeans. Sep 18, 2012 at 12:11
  • 1
    So essentially name a package plurally if it has classes that really do serve different puprposes or whatever, but which are just similarly-themed, and name a package singularly if it just contains classes that heavily focus on coming together as a sort of "meta-class" for a single purpose? Oct 22, 2013 at 18:09
  • 4
    @SkyDan's comment points out something very important that is being entirely overlooked here. It appears to me that the plural naming of "java.beans" was actually a mistake, and it should instead have been named "java.bean", singular. Nov 21, 2015 at 22:14
  • 11
    @VickyChijwani @SkyDan since JavaBeans™ is a trademark, they probably wanted to keep the name as-is to refer to the technology itself, and hence they used java.beans.
    – Hejazi
    Jul 28, 2016 at 7:52
3

This probably depends on a specific language. In .NET (C#) it most definitely should be a plural if a namespace-type name collision is likely (the type name expected but namespace found error). I've dealt with this, it's not pleasant and results in over-qualifying type names all over the code. Example.

2

IMHO

It depends on whether the package represents a container or a collection.

  • com.my.proj.core.view <- collection
  • com.my.proj.views <- container

  • com.my.lib.task
  • com.my.proj.tasks

  • com.my.lib.widget
  • com.my.proj.widgets

IMHO

  • jaba.beans should contains many real beans.
  • jaba.bean should be a collection with many 'bean relative' classes in it.

I prefer singular, unless it 'must be' plural.

Singular may not always be 'best' but always 'right'.

0

Naming things is one of the famous three hard problems.

Just as names of files are part of the user interface, and so should not contain characters like U+0004 or nonbreaking spaces, names of variables are part of the "developer interface", and should be chosen to increase understanding, reduce friction and ease development.

In this sort of situation one should consider the following, in this order:

  • Don't cause confusion
  • Comply with local policy if there is one
  • Follow best practices
  • Use your own preference

In this case I don't see it matters very much

The time you are spending on making the decision is better spent on other things.

Just pick one and move on.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.