| 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. -
With this scheme, what sort of queries will go to the catalog? -
What opportunities are there for performance improvement? -
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. |