Java programming course: 8.2 Utility classes

In the previous lesson we looked at refactoring.


Utility classes

When developing any application, it makes sense to reuse classes which have already been developed, assuming you can find something suitable, of course. This will save you the time of having to specify, code and test something from scratch, in other words from "reinventing the wheel". By the same token, if you don't find anything readily to hand it is always worth considering whether any of the classes you need to write could themselves be used in future, totally unrelated, applications.

The Person class mentioned in the previous section is a perfect candidate for such a case; it is easy to envisage many different types of application, nothing to do with zoos, that could make use of a class that models a person, provided its attributes remain generic. There are potentially several attributes that could form a general-purpose Person class, but for simplicity you will define these:

  • A String object to store the person's name, together with methods setName() and getName()
  • A String object to store the person's address, together with methods setAddress() and getAddress()
  • A Gender object to store the person's gender, together with methods setGender(), getGender(), isMale() and isFemale(). For this you can reuse the Gender enum you have already developed

A general-purpose class, such as Person, is known as a utility class. In fact, Gender is also a utility class (enum) since it too could readily be used in many different types of applications. Something that needs to be determined before proceeding though is what package to place utility classes into? While they could be placed into virtualzoo.core that would mean that other applications would need to access your entire zoo project when it only requires its utilities. A better approach is to place utility classes not only into an entirely separate package but also into a separate project. You will begin this process now, firstly by transferring the Gender enum out of virtualzoo.core and into a new project. After that, you will build the Person class, also in the new project.

In NetBeans select File | New Project..., ensure Java is selected in the Categories list and Java Class Library is selected in the Projects list. Click Next >.

For the Project Name enter Utilities and then click Finish. The new project will appear in the Projects window, above VirtualZoo if you still have that open. You can have multiple projects open in NetBeans concurrently, so if you don't have VirtualZoo open then you should open it now.

Right-click on the Source Packages node under the Utilities project and select New | Java Package..., entering com.example.util as the Package Name, and click Finish.

There is a convention when naming packages which could potentially be used in many applications, or whose name is likely to clash with other similar packages, to begin with your domain name in reverse.

If your domain is example.com then packages for your organisation should begin com.example, which are then suffixed by some other name that describes the system or application being developed. Here, you have used util as the suffix as a commonly used abbreviation of "utilities". Hence the full package name is com.example.util

If some other vendor of Java classes were to have a package of utilities and which you also needed to use, you should now be able to without a name clash, since the domain prefix should be different.

You now need to move Gender into the new project, so right-click on Gender.java under the virtualzoo.core package of VirtualZoo and select Cut. Now right-click on the com.example.util package node of Utilities and select Paste | Refactor Move..., upon which a Move Class dialog will appear. After your click Refactor a warning dialog will appear telling you that there are references in VirtualZoo to moved files. You will address this in a moment so click Refactor again to perform the move.

If you expand the com.example.util package node you will see that Gender.java has moved there and has disappeared from virtualzoo.core. If you open Gender.java you will see that NetBeans has automatically modified the package statement to reflect the new package it exists within:

package com.example.util;

public enum Gender {
    
    MALE, FEMALE;
    
}
 

You will, however, also notice some small red glyphs appearing next to a number of source files under virtualzoo.core, since these are the classes that have a reference to Gender which can no longer be found. This has occurred even though NetBeans has also automatically updated the import statement to reflect the fact that Gender has moved package. For example, if you open the Animal class you will see the correct import statement:

import com.example.util.Gender; 

Had Gender been moved to a different package within the same project then all would have been well – the class would have been found. But because it is now in an entirely separate project (so that it can be plugged into multiple applications) you need to attach it to VirtualZoo.

Under the VirtualZoo project node, scroll to the end where you should see a node called Libraries. Click the "plus" icon to expand it and notice there is currently one entry for JDK 1.6 (Default), representing the Java Development Kit that all projects need. Right-click the Libraries node and select Add Project..., then locate and select the Utilities project and click Add Project Jar Files. A new entry will appear under the Libraries node called Utilities – dist/Utilities.jar.

A JAR file is a "Java Archive". It is a type of ZIP file which consists of all classes that make up a Java project.

You should now notice that the error glyphs next to the various classes in virtualzoo.core have disappeared, since the package is now available to your application.


In the next lesson we will develop the Person utility class.

Next lesson: 8.3 Person utility class


Print
×
Stay Informed

When you subscribe, we will send you an e-mail whenever there are new updates on the site.

Related Posts

 

Comments

No comments made yet. Be the first to submit a comment
Monday, 27 October 2025

Captcha Image