Tutorials : Package Design :

Package Design

By Samudra Gumpta

Designing is probably the most important phase in the software development life cycle. In the world of Object-Oriented programming, we often spend most of our time in designing a valid and robust class hierarchy. In my previous articles, I presented a guideline to achieve robust, flexible and more maintainable class structures. In this series, I will discuss the packaging of classes that are part of the system and I will conclude this series with a small case study of the concepts discussed.

The Goal

In languages like Java, it is a common idea to place a group of classes into a package. The packages are generally perceived as a collection of classes dedicated to certain similar types of activities. For example, all the classes related to Database operation can be placed in a package called “database”.

The packages exist solely because they offer some service, which is reusable. For example, all the classes grouped into package client can potentially use the classes from the package database to perform any database related operations.

As you can see the moment package client uses the services offered by the package database, there is a package dependency. On the surface, this dependency looks trivial but great care is required in designing correct package dependencies. On the other hand, the dependency arises from the fact that the classes are placed in certain packages. Hence, it is important to consider how different classes should be packaged. In the following sections, I will present a few guiding principles about the package structure.

Package Dependency

The whole metric of a stable package design is the dependency relationship among several packages coexisting within an application. Any form of relationship between two classes residing in two separate packages results in a package dependency. In one sense, this dependency is obvious and we cannot always avoid this sort of dependency. Even though you try to put everything under one large package, you are not going to remove the dependencies, they will only be hidden. The aim is not to avoid this dependency or the coupling, which is the base of class/object oriented programming, when it cannot be avoided. The aim is to control the dependencies in the right direction and the right order.

Before we go further, we will define the concept of package dependency in a formal way.

If changing the content of package P1 can affect the content of package P2, then package P1 has a package dependency on package P2.

It is possible to represent this dependency via a UML diagram. If package A has a dependency on package B, the UML diagram will show the dependency in the following way.

This is the most fundamental formula for good package design. Knowingly or unknowingly, we follow this principle and if you find you don’t, then follow it. We will first define the terms for a better understanding of the concept:

Reuse: The reusability of a piece of code does not mean that we should be able to copy-paste the same code in many places within the application. In fact, it exactly means the opposite thing. A piece of reusable code means that the same code can be reused in different places without re-writing it. The metric of reusability is how many programs can reuse the piece of code without looking at the source code. Reusability is one of the most important ideas of object-oriented programming. Reusability of a package is dependent on the reusability of the classes within that package.

Release: Every package contains one or more functionally related classes. As a client to this package, one should not need to know the underlying implementation of the classes and the client should be able to work with the knowledge of interfaces defined by the required classes. Once the package undergoes some changes, it is required to consider a release of the whole package to the world where many clients may be using the package. This release is a means to keep track of the functionality changes that the system has undergone. The clients to this package are notified about the changes and they need to upgrade themselves to accommodate the changes.

The Release Reuse Equivalency Principle dictates that the granule of reuse cannot be different from the granule of release. Anything that we reuse must be released. This means that it is important how the classes are allocated in different packages. A package is released essentially meaning that all the classes within that package are reusable. Thus, if you add another class to any existing released package, and the class is not exactly reusable, then the package becomes non-reusable. This means that your class needs modification and it eventually means a re-release of the package itself. Care must be taken as to how and when classes can be added to the existing package structure. You also must take into account what its impact on the other packages will be.

The decision is not always easy and sometimes you will find that it is not always possible to avoid new releases of the package. As new package releases will mean that all the clients need to accommodate these changes. It is essential that care must be taken to minimize these impacts. The other points that we will discuss in the following sections will help minimize the impacts of change.

How to Add Java Applets to Your Site

New on the Java Boutique:

New Article:
Putting Design Principles to the Test (A Java based Case Study)
This month Samudra puts knowledge to work as we test the design principles governing the class and package structures that have been discussed in this series.
... [more articles]

New Tutorial:
New Tricks With Design Pattern: Java Value Types
Our newest author Noah Horton sheds some light on "Java Value Types" design pattern, an extension to the value object pattern. Developers will find that, in many respects, they are like value objects on steroids.
... [more Tutorials]

Year in Review:
The Best of 2002
The year 2002 saw 201 new applets posted to JavaBoutique. Check out the 2 most popular apps from each month of 2002!
... [popular applets]

Elsewhere on internet.com:

WebDeveloper Java
Lots of Java information on webdeveloper.com

WDVL Java
Thorough Java resource at the Web Developer's Virtual Library.

ScriptSearch Java
Hundreds of free Java code files to download.