Section 13.4. Package Dependency

13.4. Package Dependency

The previous sections showed that sometimes a class in one package needs to use a class in another package. This causes a dependency between packages : if an element in package A uses an element in package B, then package A depends on package B, as shown in Figure 13-12.

Figure 13-12. Package A depends on package B

Packages in Your Software

Now that you've seen the basics of package diagrams, it's a good time to consider why you'd want to use packages in your software.

If you're creating a very small program (consisting of only a few classes), you might not bother organizing your classes into packages. As your program gets bigger and you add developers to the project, packages introduce structure and let you know who's working on what.

Code related to the graphical user interface (GUI) can belong to a gui package, code related to search capabilities can belong to a search package, and common utilities can belong to a util package. This makes it easier to find classes when looking through a complex API. For example, to locate a GUI dialog, you would know to look in the gui package.

Often, programmers work roughly undisturbed in their own or their group's package. Those working in gui generally don't change the search package and vice versa. Everyone may use common packages, such as the util package, but such commonly used packages are expected to be fairly stable since changes could affect everyone.Beyond organizing elements, packages can serve other useful functions. They can be used for access control: you can declare elements private to a package to prevent it from being used by other packages.

Packages can assist with organizing classes as deployment modules. For example, if you wanted to include search capability in some systems but not others, you could choose to include or exclude the search package in the build.

Understanding the dependencies among your packages is useful for analyzing the stability of your software, as discussed in "Managing Package Dependencies." In fact, the most common use of UML package diagrams is to give an overview of the core packages in your software and the dependencies among them, as shown in Figure 13-13.

Figure 13-13. A typical package diagram featuring core packages and dependencies

"Managing Package Dependencies," later in this chapter, revisits package dependency diagrams, showing you how to use them to understand and improve the stability of your software.