Java Reference
In-Depth Information
return (Firework) Collections.min(list, c);
}
This code creates and applies a
Comparator
object that reflects the client's specific need to
know the cheapest firework. If the client wants, say, a list of fireworks sorted by price, you
can add yet another method to the
FireworkList
class. If you don't think that you can keep
up with client demands, make your collection class a subclass of
ArrayList
or another class
from
java.util
. The tradeoff is between offering flexibility versus providing type safety
and applying domain-specific knowledge about what is important about your collection.
By creating type-specific collections, you can strengthen the contract between your code and
your client's code, reducing the chance for defects. Iterators are a natural extension to
collections, and it is usually worthwhile to accompany a type-specific collection with a type-
specific iterator. Another occasion for supplying an iterator may occur when you create a new
collection type, such as a composite.
Iterating Over a Composite
In Challenge 5.3, from Chapter 5, Composite, you developed recursive behaviors that execute
by traversing a composite structure. Iterators introduce a new challenge when working with
composites, because you want to return control to a client as you traverse each node.
You might think that you would need a new iterator class for each domain-specific composite
you model. In fact, you can design a fairly reusable composite iterator, although you have to
arrange for domain classes to be able to instantiate your iterator. You may also need to handle
composites that contain cycles.
As an example of a composite structure that you might want to iterate over, recall
the
ProcessComponent
hierarchy that Chapter 5 introduced. Figure 28.2 shows the process
composite hierarchy that Oozinoz uses for modeling the manufacturing work flows that
produce various types of fireworks.
Figure 28.2. Manu-facturing process flows at Oozinoz are composites.
