Newsletter sign-up

View all newsletters

Sign up for our technology specific newsletters.

Enterprise Java

Email Address:

Unwrap the package statement's potential

Minimize project complexity and maximize code reuse

By Laurence Vanhelsuwé, JavaWorld.com, 02/21/03

Page 2 of 7

Soon, creating a new package for each new Java project becomes second nature. Unfortunately, many Java programmers' understanding of package's true potential stagnates at this point. But continuing to use Java's package feature in this primitive way is wholly unsatisfactory in the long term, especially where code repositories grow in size from mere molehills to mountains.

Code duplication: the big no-no

The long-term problem of simply creating a new package for each new project is code duplication. Code duplication is one of the big evils of programming because:

• Maintenance costs can spiral out of control
• Readability suffers
• Code becomes bloated
• System performance might turn sluggish

We all know the root of this problem: trademark programmer's laziness. Often we get the feeling we're working on something that we've already done or solved in some distant past, so we hunt down the old solution, copy the appropriate code (logic snippet, entire method, or (hopefully not!) entire classes), and joyfully paste this into our new project. Hence the expression cut-and-paste programming.

If you shiver at the thought of your Java code repository being littered with multiple copies of near-identical bits of logic, methods, or even classes, then you need to unleash the package statement's true power in your day-to-day Java development methodology.

The Big Bang...uh, I mean split

Let's approach the code duplication problem logically: to outlaw and eradicate all code duplication, any nontrivial piece of code should only occur once and once only. This means, among other things, that any and all

• Generic logic
• Generic data groupings
• Generic methods/routines
• Generic constants
• Generic classes
• Generic interfaces

should never be declared in an application-specific package.

This key observation leads us to the package organization Golden Rule Number 1:

Golden Rule Number 1
Never mix generic code with application code directly Below your com.company or org.yourorg package level, split your package hierarchy into two fundamentally incompatible branches: The reusable items branch The project-specific branch

Application code always uses generic code (library classes and routines) but never contains such code. The opposite is true also: library code never contains any application-specific code or even application dependencies.

If you have never considered these two fundamentally different kinds of code, then you need to start thinking about this fundamental code dichotomy in your daily programming routine. It is the key to unleashing true code reuse in your organization and banishing code duplication once and for all.

This black-and-white code perspective applied to packages logically requires a topmost-level branching into a generic/reusable package master branch and a nongeneric/nonreusable (i.e., application-specific) master branch.

So for example, for the past five years, I've split my org.lv top-level Java namespace into org.lv.lego and org.lv.apps. (lv stands for nothing more exciting than my initials.) Both these fundamental top-level branches are then further subdivided into more detailed subpackages. My lego branch, for example, is currently subdivided into the following subpackages:

 

Improve efficiency with Visual Studio(r) 2010 Beta 2. - Microsoft

About Us | Advertise | Contact Us | Terms of Service/Privacy

Copyright, 2006-2008 Network World, Inc. All rights reserved.