Path 2: Query.matchesIn(catalog)

To explore another way of doing things, we'll start over with the same setup() routine, but a different test:

 Query query = new Query("shirt"); List list = query.matchesIn(catalog); AssertEquals(2, list.size()); 

Exercise 85 A Different Test.	Implement Catalog and Query for this test. (You'll probably loop over items and call query.matches(item) somewhere inside.)
Exercise 86	Refactor StringQuery to be a subclass of Query (as before).
Exercise 87 OrQuery Again.	Implement OrQuery. It should use matchesIn(catalog) on each of its subqueries.

You probably found that List wasn't the most convenient type; you'd really prefer a Set (so the OrQuery doesn't produce duplicates). You can change the List types to Sets, but you might also take this as a warning: Perhaps the result wants to be its own object, or perhaps the result of a query is another catalog.

Exercise 88 Items versus Sets. (Challenging).

At some level, this seems more complicated than the earlier implementation. I think it's because the earlier one compared individual items, and this one deals in sets.

1. With this scheme, what sort of queries will go to the catalog?

2. What opportunities are there for performance improvement?

3. Describe this version as an implementation of the Interpreter pattern.

See Appendix A for solutions.

The first optimization exposed information about the query (words to filter by) to the catalog. The second optimization exposed information about the catalog (sets of items) to the query.