Predicates as Composites

A predicate is a mathematical expression that evaluates to true or false. Given two predicates, you can create another, larger predicate by applying the operator and or or to them. This larger predicate is called a composite and the two smaller predicates are its components. You can continue this process for as long as you like, building up larger and larger composite predicates. A noncomposite predicate is called a basic predicate.

A composite predicate can be represented as a tree whose internal nodes are the operators {and, or} and whose leaves are basic predicates. Figure 9-1 depicts the predicate tree for Listing 9-1.

Figure 9-2 contains a class diagram that shows the relationship between these Predicate classes. The three “BasicPredicate” classes correspond to the anonymous classes created for pred1, pred2, and pred3 in Listing 9-2.

The class diagram looks very much like the decorator pattern. The difference is that the wrapper class CompositePredicate wraps two objects instead of one. To highlight this difference, the dependency arrow is annotated with the optional cardinality label “2.”

The first way uses the AndPredicate and OrPredicate classes. Predicate pred4 is an OrPredicate object and predicate pred5 is an AndPredicate object. The diagram of Figure 9-3 depicts these five Predicate objects in memory. The diagram is similar to the memory diagram of Figure 8-3, in that each object is represented by a rectangle and the values of its global variables are shown within its rectangle. Note how the object references form a tree that corresponds exactly to the predicate tree of Figure 9-1.

After creating the predicate pred5, the code of Listing 9-5 passes pred5 to its printUsing method, which calls the predicate’s test method on the integers from 1 to 100. Figure 9-4 depicts a sequence diagram that traces the execution of the expression pred5.test(9). Step 2 calls the test method of pred5’s first component, pred1, which returns true. Step 4 then calls test on its second component, pred4. In order to determine its response, pred4 calls test on its two components. Component pred2 returns false but pred3 returns true; thus pred4 can return true. Since both components of pred5 have now returned true, pred5 returns true.

Note how the call to test(9) gets passed from the root of the predicate tree down to its leaves. In fact, this sequence of method calls corresponds to a postorder traversal of the tree.

The classes AndPredicate and OrPredicate are not part of the Java library. Instead, the Predicate interface has the default methods and and or, which make it possible to create composite predicates without having to create the composite objects yourself.

The use of these methods is illustrated in the second and third parts of Listing 9-5. The variable pred6 returns true if either pred2 or pred3 is true, and is functionally equivalent to pred4. Similarly, the variable pred7 is functionally equivalent to pred5. The calls to the and and or methods can also be composed, as shown by variable pred8.

Composite Objects in JavaFX

For a second example of composite objects, consider a library for building GUI applications. When you create an application window, you often structure its contents as a composite object. For an example, Figure 9-5 depicts a window that I created using the JavaFX library.

In JavaFX, a window’s content is constructed of nodes. The JavaFX library has classes to implement several types of node. This example window uses two types of node: controls and panes.

A control is a node that can be manipulated by the user. All controls in JavaFX extend the abstract class Control. The controls in the example window belong to the classes Label, ChoiceBox, CheckBox, and Button.

A pane is a node that can contain other nodes, called its children. Each pane is responsible for determining where its child nodes are placed on the screen. This is called the pane’s layout strategy.

The JavaFX library has several pane classes, each with its own layout strategy. They all extend the class Pane. The example window uses two of them: HBox and VBox. An HBox pane lays out its children horizontally. A VBox pane lays out its children vertically.

The window of Figure 9-5 has nine nodes: five controls and four panes. Figure 9-6 depicts their layout.

An alternative way to depict the structure of a window is to use a tree whose interior nodes are the panes and whose leaf nodes are the controls. This tree is called the window’s node hierarchy . Figure 9-7 depicts the node hierarchy corresponding to Figure 9-6. The labels on these nodes correspond to the variable names in the JavaFX class AccountCreationWindow, which is the code that implements the window.

This technique is very similar to the way that Thread uses the template pattern (as you may recall from the end of Chapter 3). The difference is that unlike Thread, a client cannot create an Application object by simply calling the Application constructor. Instead, the static factory method launch is responsible for creating the Application object and running it in a new thread. The advantage of using a factory method is that it hides the application thread from the client, thereby shielding the thread from improper use.

The launch method also creates a Stage object, which manages the window’s frame. For example, the Stage method setTitle specifies the string to be displayed in the window’s title bar. The launch method then calls the application’s start method, passing the Stage object as the argument.

The start method of Listing 9-8 calls createNodeHierarchy to create the node hierarchy. It passes the root of that hierarchy to a new Scene object, and then sends that object to the stage via the setScene method.

The controls behave as follows. A Label object displays a string. The string’s initial value is specified in the constructor, but its value can be changed at any time by calling the setText method. A CheckBox object displays a check box and a descriptive string. Its isSelected method returns true if the box is currently selected and false otherwise. A ChoiceBox object allows a user to select from a list of objects. The getItems method returns that list, and the getValue method returns the object chosen.

A Button object has a label and performs an action when fired. Its constructor specifies the label. The method setOnAction specifies its action. The argument to setOnAction is an EventHandler object. Chapter 10 will examine event handlers in more detail. For now, it suffices to know that this event handler is specified by a lambda expression whose body contains the code to execute when the button is clicked.

The lambda expression in Listing 9-9 calls the check box’s isSelected and the choice box’s getValue methods to obtain the type of the new account and its foreign ownership status. It then constructs a message describing these choices and sets the text of the title label to that message. In particular, if a user chooses the type “Checking,” checks “is foreign,” and clicks the button, the title label will display “Foreign Checking Account Created.”

You might be disappointed that clicking the button does not actually create an account. The problem is that the window cannot create an account without having a reference to a Bank object. Chapter 11 will discuss the proper way to connect banking information to a window, so you will need to wait until then.

Panes behave as follows. Each Pane object has the method getChildren, which returns the list of its child nodes. A client can modify the contents of the list at any time. Its setPadding method specifies the number of pixels in the margin around the pane.

A pane’s setBackground method specifies its background. Pane p3 of AccountCreationWindow demonstrates its use. The BackgroundFill object specifies a solid-colored background. (Another possibility is to use a BackgroundImage object, which specifies an image as the background.) The three arguments to BackgroundFill specify the color, the roundedness of the corners, and the size of the margin around the background.

The constructors shown for VBox and HBox take one argument, which is the number of pixels between their children. Their setAlignment method specifies how the children should be aligned. Since not all Pane subclasses support this method, it must be defined nontransparently in VBox and in HBox.

Figure 9-8 shows the class diagram for the JavaFX Node classes described in this section. This diagram deliberately omits a lot of JavaFX classes, which makes it appear far simpler than it is in reality. This simplicity makes it easier to understand the design principles underlying JavaFX. A full discussion of the JavaFX node classes is outside the scope of this book.

Note how this class diagram is similar to the Predicate class diagram of Figure 9-2. The base classes are the subclasses of Control. The wrapper class is Pane and its subclasses are the recursive classes. The dependency arrow from Pane to Node has the label “*” to indicate that a pane can wrap an arbitrary number of nodes.

The Node interface declares many methods; the class diagram of Figure 9-8 shows just three of them. Every node holds a string that can be used as its id. By default, the id is the empty string. The method setId sets the id and the method getId returns it.

Every node also needs to know its size and location. The method getLayoutBounds returns a value of type Bounds. A Bounds object contains the height and width of the node, as well as the coordinates of its top left corner.

Controls and panes calculate their sizes differently. The size of a control is determined by its properties. For example, a label’s size depends on the text to be displayed and the size and type of its font. The size of a pane is based on the sizes of its children plus any additional space determined by the layout algorithm (such as the space between the children).

The getLayoutBounds method can be implemented as a postorder traversal of the node hierarchy. The size of the root pane depends on the sizes of its children, which depend on the sizes of their children, and so on until the Control objects are reached.

This code is a stripped-down version of AccountCreationWindow, containing only two panes and three controls. It creates the window shown in Figure 9-9.

Let’s make sense of this output. First consider pane p2 and its children label and chbox. These controls calculate their own sizes. The program output asserts that chbox is a bit higher and wider than label, which is borne out by the screenshot. Pane p2 is a VBox, which means that its width should be the same as its widest child, which in this case is chbox. The height of p2 is the sum of the heights of its children plus 10 pixels to account for the space between them. These values are verified by the program output.

Now consider pane p1 and its children p2 and btn. Pane p1 has 10-pixel margins on all four sides. Thus its height and width will be an additional 20 pixels larger than the values calculated for its children. Pane p1 is an HBox, so its height will be the maximum height of its children (which in this case is the height of p2) plus 20 pixels for the margins. The width of p1 is the sum of the widths of its children plus 10 pixels for the space between them plus 20 pixels for the margins. These values are also verified by the program output.

The Composite Pattern

You have so far seen two examples of composite objects: Java predicates and JavaFX nodes. Although these objects come from wildly different domains, their class diagrams—as pictured in Figures 9-2 and 9-8—are remarkably similar. This similarity is known as the composite pattern.

The composite pattern expresses the preferred way to create tree-structured objects. Its class diagram appears in Figure 9-10. A tree consists of objects of type Component. These components are either of type CompositeComponent or BaseComponent. A BaseComponent object has no children and will be a leaf of its tree. A CompositeComponent object can have any number of children (thus the “*” label on its dependency arrow) and will be in the interior of the tree.

The Component interface specifies the methods that all components will have; these methods are not shown in the diagram. CompositeComponent is an abstract class that contains methods to modify a composite object’s list of children.

The class diagram of the composite pattern is similar to that of the decorator pattern. Their only difference is that a decorator class wraps only one object, whereas a composite class can wrap multiple objects. Consequently, decorators form a chain and composites form a tree.

This difference has a profound impact on how decorators and composites are used. A decorator chain has a single endpoint, which is treated as the primary object of the chain. The remaining objects on the chain are “decorators” that enhance the behavior of this primary object. On the other hand, a composite tree has multiple leaves, none of which is primary. Instead, its primary object is the root of the tree. The root treats its children as “assistants,” relying on them to help compute the answer to its methods. That is why composite methods are often implemented as tree traversals.

The class CompositeComponent in Figure 9-10 contains two methods for managing the children of a composite object. This design is one out of many possible designs. For example, the JavaFX Pane class has the single method getChildren to manage its children.

Moreover, the Predicate hierarchy has no child-management methods. When a composite Predicate object is created, its children are assigned by the constructor and there is no way to change those children afterwards. Such a design is called static. Composite designs that have methods to add and remove children are called dynamic.

A designer of a dynamic composite can decide to place the child-management methods either in the composite interface or in the abstract wrapper class. The choice shown in Figures 9-8 and 9-10 is to place the methods in the wrapper class. This decision causes the methods to be nontransparent. For example, consider the getChildren method in JavaFX. This method is defined in Pane, which means that it cannot be called by variables of type Node. Note that variables p1, p2, p3, and p4 in Listing 9-9 belong to classes VBox and HBox, and not Node.

The alternative design is to move the modification methods to the Component interface . This design achieves transparency, but at the cost of safety. With such a design, a client could add a child to a base object even though doing so would have no legitimate meaning.

The add method places button b2 in the list of b1’s children. But since b1 (justifiably) ignores this list, b2 will never be displayed. This sort of bug can be quite difficult to uncover.

A Cookbook Example

For a third example of the composite pattern, consider the task of writing a program to manage the recipes in a cookbook. A recipe consists of a list of ingredients and some directions. An ingredient can be a “basic food” such as carrot, apple, or milk; alternatively, it can be the result of another recipe. Figure 9-11 displays an example recipe.

The first order of business is to design the recipe classes. Since a recipe can include other recipes as well as basic foods, the composite pattern is indicated. Figure 9-12 gives a reasonable class diagram. It contains a class for basic foods and a class for recipes. Both classes implement the FoodItem interface . The Recipe class also has a dependency on FoodItem, which denotes its list of ingredients.

The last two methods of FoodItem enable clients to examine the components of a food item. The childIterator method returns an iterator that contains the children of the given food item. If the item is a recipe then the iterator contains its ingredients; if the item is a basic food then the iterator will be empty. The iterator method returns an iterator that performs a complete traversal of the tree rooted at a given object. The iterator method is implemented as a default method of the interface, in terms of the class FoodIterator. That class will be examined in the next section.

Traversing a Composite Object

A composite object typically has methods that traverse the object’s components. Examples are the method test in Predicate, the method getLayoutBounds in Node, and the method isVegan in FoodItem. These methods are called internal tree traversals because the traversal occurs inside the methods without the knowledge or control of the client. The concept is analogous to the concept of internal iteration discussed in Chapter 6. These internal tree traversals, like internal iterators, are task specific.

This section is concerned with the question of whether the clients of a composite should be able to perform customized tree traversals, and if so, how. The Predicate interface , for example, was designed so that customized traversals are not possible. The designers omitted any method that would enable a client to examine the structure of a predicate, meaning that there is no way to determine the base predicates of a given Predicate object or even to tell if it is composite. The only way to traverse a Predicate object is to call its test method.

Although the getChildren method can be used in this way for customized traversals of Node objects, it is somewhat unsuited for that purpose. The method is defined in Pane, which means that it cannot be used transparently. The result is that the code in listings 9-17 and 9-18 require if-statements and awkward type casts.

Listing 9-26 gives the code for printShoppingList. This method prints the name and quantity needed for each basic item used in a recipe. The second argument to the method is the number of portions of the recipe that will be made. One complexity to the code is that the quantity of each item in the recipe must be multiplied by the number of portions of its recipe that are being made.

The next method essentially performs a nonrecursive tree traversal using a stack of iterators. Each call to next removes an item from the topmost iterator. If that iterator has no more elements then it is popped from the stack. If the retrieved item has children then its child iterator gets pushed onto the stack. The hasNext method returns true if the stack is not empty. The constructor primes the stack by adding an iterator containing the root of the composite hierarchy.

Summary

A composite object has a hierarchical structure. Each object in the hierarchy implements the same interface, called the composite interface . The composite pattern describes the preferred way to organize the classes of a composite object. These classes form two categories: base classes, whose objects are the leaves of the composite hierarchy, and recursive classes, whose objects form the interior of the hierarchy. Each recursive object wraps one or more objects that implement the composite interface. These wrapped objects are called its children.

Syntactically, a composite object is very similar to a decorator object; the only difference is that a composite can have multiple children whereas a decorator can have just one. This difference, however, completely changes their purpose. A decorator is a chain, where the recursive objects serve to enhance the methods of the base object at the end of the chain. A composite is a tree, whose nonroot objects combine to execute the methods of the root. A composite method is often implemented as a tree traversal.

When designing classes that conform to the composite pattern, you need to consider the transparency of their methods. A method that modifies a composite’s list of children should not be defined in the composite interface, as it will allow clients to perform meaningless (and potentially dangerous) operations on base objects. It is better to define such methods in the wrapper class and use them nontransparently. On the other hand, it is possible to design methods for the composite interface that enable clients to transparently traverse the composite hierarchy. This chapter presented two such methods: childIterator, which returns an iterator containing the object’s children, and iterator, which returns an iterator containing the entire composite hierarchy. Implementing the iterator method also lets the composite interface extend Iterable, which means that clients can use the forEach method and the for-each loop to examine composite objects.