0

Is there are any rule of thumb that relates to whether your package structure should allow access of a class from another class in a sibling package.

An example I have a class that represents a Login page: 

project.page.login.LoginPage

And a class that represents an Account home page:

project.page.account.AccountHome

Both pages access the std chrome for the project (Header, Footer, Menu stuff and BasePage), is it better to put thoses classes in a sibling package e.g. project.page.chrome

project.page.chrome.BasePage
project.page.chrome.Menu
project.page.chrome.Footer
project.page.chrome.Header

or in the parent package:

project.page

e.g.

project.page.BasePage
project.page.chrome.Menu
etc

I know that this is a stylistic rule of thumb question, which in a way is subjective.
What I wish to know is if there is a commonly accepted rule for this sort of thing. And if so what is the reasoning behind what are the problems or benefits associated with each approach.

Further to Vampire's answer. My question is not whether you can reference classes from one sibling package to another. It's whether you should and what are the reasons (either way).

Simon B
  • 1,784
  • 3
  • 21
  • 26

5 Answers5

1

There is no such thing as a parent- or child-package. Each package in Java is completely stand-alone. Having them named hierarchically and stored like that in the filesystem is just a convention, but technically, those packages are all absolutely non-related stand-alone packages.

It is totally up to you how you like to organize your source-code in packages.

marc_s
  • 732,580
  • 175
  • 1,330
  • 1,459
Vampire
  • 35,631
  • 4
  • 76
  • 102
  • My question is not about whether you **can** but whether you **should**. For example you can name your local method variables a1, a2, a3 etc but as a rule of thumb you shouldn't because it would be confusing and show's no intention or description of what you code is intended for. – Simon B Aug 08 '16 at 08:50
  • Well, as I said in the second paragraph, it is totally up to you. And basically this question is heavily opinion-based and thus should be closed as off-topic like the SO rules suggest. ;-) – Vampire Aug 08 '16 at 09:25
1

There is no conventional way to name your packages or grouping your classes in packages. But most of the time people tend to follow the standard Java APIs, and adopted the style from those. (to name a few) For e.g.: util, common, basic

Jude Niroshan
  • 4,280
  • 8
  • 40
  • 62
1

you can use this but the best way is to review your specification and make it the most possibly readable and extendable.
the best advice I can give you is learn the rules then forget them to make yours

whyn0t
  • 301
  • 2
  • 14
1

There are maybe not exact rules but some guidelines. Link to answer to another similar question Since this answer appears on SO, pasting only the link here. Reading the Uncle Bob articles may give you some pointers.

Community
  • 1
  • 1
Atul
  • 2,673
  • 2
  • 28
  • 34
0

Package allows to combine the related classes/packages together with proper abstraction. Technically, in Java there is no rule that sibling packages should allow class access from each other. From design approach and good practices point of view, it is advised to group the classes/packages in a structured and intuitive way. For eg.,

   project.page
   project.page.login
   project.page.chrome
   project.page.account

This facilitates in modularizing and unit testing of the application. Also, proper package hierarchy helps in quick debugging of the application using tools like log4j.

Omkar Shetkar
  • 3,488
  • 5
  • 35
  • 50