10

Apart of the code conventions to use camelCase, PascalCase etc., are there any conventions for naming packages and classes in Java?

For example, I have an mvc project and the main package is com.myproject. In this package I have:

  1. com.myproject.model
  2. com.myproject.view
  3. com.myproject.controller.

Is there any convention or best practise to give a name to the class in these 3 packages? Like for the package 1 avoid model in the classname, or something like this? And if I want to use the same class name like User, what is better: to use UserModel, UserView, UserController, or give the same name to the 3 classes? Is there some kind of best practise or naming convention to do this?

Dan Pichelman
  • 13,853
Liz Lamperouge
  • 233

4 Answers4

20

Short answer: Naming two classes the same in the same project/library/context is not advisable.

Aside from the obvious inconvenience, there is a deeper point why it isn't a good idea and neither is your proposed package naming. We as developers are responsible for modeling business problems, and our naming vocabulary should reflect this fact. This is kind-of the point of Domain Driven Design.

Putting the technology above the actual function might be logical for us, because we are more interested in technology, patterns, architecture and things like that, but makes our model less expressive, less maintainable.

My point is: Package names and class names should reflect business concepts. There should be no model, view, controller packages, there should be no UserModel, UserController classes, etc.

Model the problem, not the technology! Find suitable abstractions straight from the business requirements and hide implementation details, like the fact that you are using MVC.

Robert Bräutigam
  • 12,340
6

Regardless of language, but specifically in Java, you want to, more or less follow these guidelines:

  1. Classes named after nouns (Printer, Controller, Mailbox, Manager, Handler), meaning, something, an entity that makes sense in your problem domain.
  2. Interfaces as adjectives (Iterable, Serializable, Secured, Asynchronous), meaning, a capability or characteristic of an entity implementing said interface.
  3. Methods as verbs or in some cases, adverbs or adverbial clauses, whichever makes sense to describe an action (execute, deliver, validate)
  4. Packages as a grouping of things that make sense to be together (again, this is very strongly tied to your problem domain.)

Beyond these general guidelines (not rules, but guidelines or suggestions), it is hard to give concrete examples without having a concrete problem domain.

We want to define a problem domain independently of the programming language, one that describes the functionality you need, and the entities that deliver the functionality, and the interactions between them.

Then and only then you have a starting point to start naming classes, packages and methods.

luis.espinal
  • 2,620
2

Naming conventions are pretty much left to the developer or team most of the time. For me personally, I have almost always relied on the information published via Oracle when working in Java.

http://www.oracle.com/technetwork/java/codeconventions-135099.html

More directly related to your question, if you wanted to have a class called "Person" in all three packages, that would be permissible. When you want to include those packages somewhere and actually use the classes therein, that is where you will see that it may or may not be a good idea.

Looking at your package names for example, "com.myproject.model" why would you have a class called "Model" versus something else, such as "Person" or "Order"?

Maybe I am misunderstanding the question but it makes more logical sense to me for it to be used in this way such as in the following pseudocode:

com.myproject.model.Person x = new com.myproject.model.Person();
RobertMcAtee
  • 51
1

In general, giving the same name to multiple classes in the same project (not package, project) is a bad practice. Among other bad things that can happen, if these things need to refer to one another, it becomes ambiguous which, for example, "User" you are trying to instantiate when you create a new User.

In MVC, the way I've usually seen it done is your package is named com.MYNAME.PROJECTNAME, and then add .MODULENAME for each module (in your case, "model", "view", "controller", etc)

As for classes, your class name should say what the class is. If it's a Controller for your User object, then it should be called UserController. This is true even if the package is the "controller" module; when looking at code in an IDE, it is easy to mistake or forget which package you're looking at for any given file.

Ertai87
  • 187