Creating Java Packages

What are the heuristics for identifying Java packages? How analogous is the whole exercise to Bobby Woolf's patterns in PartitioningSmalltalkCodeIntoEnvyDeveloperComponents? I've been using PackagePerLayer and sometimes SubPackagePerSection?, but then in other cases I have packages which are orthogonal to architectural layers. --RandyStafford

Personally, I always try to apply Bobby's rules. However, sometimes you come up with packages that are, as you say almost "orthogonal" to architectural layers. In this case, I often see them as being a separate, vertical stack that crosses many layer boundaries. An example would be "java.util" or "javax.naming". So, my point is to follow Bobby's rules unless you come across a set of "Utility" classes, in which case the naming convention should reflect the overall function of the classes in the package.

KyleBrown

Discussion:

Are there accepted idioms for naming packages under your domain? For example, is there a set name for the package that contains debugging classes, application framework classes, GUI classes? When you are packaging your classes for reuse, how should the package hierarchy be structured. CraigLarman suggests using names like util, framework, ui. Has Sun published and standards on package names (i.e. after the com.abc part)? -- RobertDiFalco

Robert- The only thing I've seen from Sun is http://java.sun.com/docs/codeconv/index.html, which doesn't really address the level of detail we're talking about here. If you agree with Kyle and me that Bobby Woolf's patterns apply in Java, then its just a matter of choosing a FunctionRevealingPackageName, as Kyle puts it. Applying PackagePerLayer in FoodSmart yielded packages named web, distribution, services, entities, domain, and persistence. Applying LayerIndependentPackage resulted in packages named admin, io, security, and util. -- RandyStafford

Yeah, there really is nothing from Sun that I have seen. I tend to follow CraigLarman for package names and JohnLakos for rules regarding package interdependencies. I haven't taken the time to read http://c2.com/ppr/envy/. I'll check it out. Wouldn't the hierarchical naming scheme of Java provide opportunities that are different from SmallTalk? Anyway, while it seems that there are many idioms available, there are no generally accepted, defacto standard convention used by reusable asset vendors. To really pick a nit -- it's also troubling that there are no conventions regarding abbreviations versus whole words versus acronyms. For example, in your LayerIndependentPackage results we have two abbreviations (admin and util), one whole word (security), and one acronym (io). Same with Larman, we have ui (an acronym), util (an abbreviation), and framework (a whole word). -- RobertDiFalco

I usually follow Sun's model if I can and beyond that I use package names that reflect the words I use in real life. So the acronym (io) makes sense 'cause I would never actually say Input slash Output when referring to it. I also frequently refer to apps I have installed or utils that really helped me out.

I generally use a mixture of PackagePerLayer and LayerIndependentPackage. This means I would have util, io, security as well as gui and db for example.-- IainLowe

See JavaPackageNames

CategoryJava