1.5 The Union and Composite Patterns

In our department directory example, an object of type Entry only has one form, namely an instance of class Entry. If we were designing the data for a more comprehensive directory such as a city phone directory, we would need more than one form of entry. At a minimum, we would need entry formats suitable for business listings, government listings, and residential listings. For such a phone directory, we might define an entry as follows.

A CityEntry is either:

• a BusinessEntry(name,addr,phone,city,state),
• a GovernmentEntry(name,addr,phone,city,state,gov), or
• a ResidentialEntry(name,addr,phone),

where

• name is a string specifying the name for the listing,
• addr is a string specifying the street address for the listing,
• phone is a string specifying the phone number (with area code) for the listing,
• city and state are strings specifying the city and state for the listing, and
• gov is a string specifying the government entity for that the listing, e.g. the "City of Houston".

The BusinessEntry and GovernmentEntry forms include city and state information because businesses and government agencies that serve clients in cities outside their local calling area often elect to have their phone numbers included in the directories of other cities (in addition to the cities where they are located). In addition, government listings include a string specifying the government entity to which they belong. For example, a listing for the Federal Bureau of Investigation would specify the "U.S. Government" as the gov field.

In Scheme, we could represent such an entry data type by defining three different structures:

;; a CityEntry is either:
;;   a BusinessEntry 
;;     (make-BusinessEntry name addr phone city state), 
;;   or a GovernmentEntry 
;;     (make-GovernmentEntry name addr phone city state gov),
;;   or a ResidentialEntry 
;;     (make-ResidentialEntry name addr phone).

(define-struct BusinessEntry (name addr phone city state))
(define-struct GovernmentEntry (name addr phone city state gov))
(define-struct ResidentialEntry (name addr phone))

Note that the type CityEntry consisting of the union of the types BusinessEntry, GovernmentEntry, and ResidentialEntry is not defined in program text because all union types in Scheme are implicit.

In Java, we can define the CityEntry type by introducing a ``dummy'' CityEntry class that we extend by ``concrete'' classes^1.4 for each different form of Entry data. In object oriented languages like Java, such ``dummy'' classes are called abstract classes. This technique--using a ``dummy'' superclass to group together related concrete classes--is called the union pattern. It is very widely used on object-oriented programming. In this pattern, an abstract class serves as the root of a hierarchy of subclasses called variants, which are the component types of the union. In this example, there are three variant classes: BusinessEntry, GovernmentEntry, ResidentialEntry. The following Java code defines the city-entry type:

  

Figure: Part I of the City Directory union class hierarchy

 

Figure: Part II of the City Directory union class hierarchy

Note that each concrete class includes exactly the same fields as the corresponding Scheme structure definition. The pivotal differences between the Java code and the corresponding Scheme code are

• (i) the presence of the abstract class CityEntry in the Java Code identifying the union type which is left implicit in Scheme and
• (ii) the explicit definitions of constructors and accessors (selectors) in the Java concrete classes which are automatically generated by the Scheme structure definitions.

The Java code in the CityEntry example above involves several concepts that we have not discussed before.

• The attribute abstract attached to the class CityEntry indicates that CityEntry is a ``dummy'' class that cannot be instantiated. The class CityEntry is defined solely to group the concrete classes BusinessEntry, GovernmentEntry, and ResidentialEntry as a type that includes all three kinds of data.
• The concrete classes BusinessEntry, GovernmentEntry, and ResidentialEntry are the only subclasses of the class CityEntry. Hence, the only values of type CityEntry are the instances of the classes BusinessEntry, GovernmentEntry, and ResidentialEntry.
• Each concrete class includes a constructor definition that specifies how new instances of the class are initialized. Each concrete class also includes getter (accessor) methods (like getPhone) to get the values of the various fields of the class.

The following expression creates a BusinessEntry for Rice University

new BusinessEntry("Rice University", "6100 Main Street",
                  "713-348-8101", "Houston", "Texas")

This syntax is wordy but straightforward. Don't forget to include the keyword new at the front on each constructor invocation!

Finger Exercise Enter the preceding class definitions into the definitions window of DrJava. Compile this program and evaluate the following expressions in the interactions window:

BusinessEntry e1 = 
  new BusinessEntry("Rice University", "6100 Main St.",
                    "713-527-8101", "Houston", "TX");
ResidentialEntry e2 = 
  new ResidentialEntry("Robert Cartwright",
                       "3310 Underwood Street", "713-660-0967");
e1.getName()
e2.getName()

Did you get the results that you expected?