No Subject

1) By convention package names are all lowercase: "javax.swing.table"
2) Package names must be unique so there are no collisions with 3rd-party libraries. Most often your package should start with your internet domain name (but reversed): "com.verizon.billing" if the domain is "verizon.com".
3) Code unique to a particular application should have the application name following the domain name: "com.verizon.billing" for example if the application is called "billing".
4) Code that might be reused for several applications should not have the application name included in the package (since it will be used for several applications): "com.verizon.dialogs" could hold several general-purpose dialog classes.
5) The number of classes per package is a bit arbitrary but I generally aim to have packages with more than 2 classes and fewer than 50 classes. A package should contain enough classes to be useful and few enough to be manageable.
6) Classes should be divided between packages based on related functionality. View your packages as a tree. The first branches are usually something like "userinterface", "dataaccess", "utilities". If there are many classes in a branch look for a way to subdivide it for example "userinterface" might have subpackages "userinterface.printing", "userinterface.animation", etc. Continue to subdivide your packages until they are of reasonable size and logical separation.
7) I will often use common abbreviations for package names to keep them short. This way you can refer to "com.verizon.ui.img" instead of "com.verizon.userinterface.images".

Here's an example for a simple chess-playing app. Obviously there would be several more classes needed to fully implement the application, this is just an example to show package grouping.

com.xyzcorp.utils
	FileIO.java
com.xyzcorp.uiutils
	PrintPreviewDlg.java
com.xyzcorp.chess
	ChessApp.java
	Strategy.java
	ChessRules.java
	InvalidMove.java
com.xyzcorp.chess.ui
	ChessBoard.java
	ChessPiece.java
	PreferencesDlg.java
	ErrorDlg.java
com.xyzcorp.chess.bruteforce
	BruteForceStrategy.java
	MoveAnalyzer.java
com.xyzcorp.chess.followtheleader
	FollowTheLeaderStrategy.java
	GamesOfTheMasters.java
	

Samuel Crank
Sr. Software Engineer
Northridge Systems


-----Original Message-----
From:	Lee Chalupa [mailto:lchalupa@seelink.org]
Sent:	Mon 11/3/2003 10:08 PM
To:	Ajug Members
Cc:	
Subject:	Need Development Guidelines To Organize Classes into Packages
Hello:

I am looking for some guidelines to help me organize a new application's 
classes into packages.

Is there a quantity of classes per package that tends to be easier to work 
with?  What number of classes per package is definitely too few?  What is 
definitely too many? Why might this be a problem?

Should you consider some kind of fan-out ratio when you are organizing the 
package hierarchy?

How would you go about evaluating the quality of a packaging scheme for an 
application?  What does goodness look like? For example, high cohesion 
inside packages, low coupling between packages, intuitive package names, a 
consistent range of quantity of classes in each package of the application.

Does anyone have any references for these kind of development issues?

Thanks

Lee



-- 
Lee Chalupa
Something Else Enterprises, Inc.
lchalupa@seelink.org
770 381 2377