Refactoring Workbook

A. This feels natural to write, but the catalog has to know about the query.

B. The query has to know about the catalog.

C. The catalog and the query needn't know about each other, but they each must expose some of their own information.

It was Primitive Obsession because our query was originally just a string. You might call it Feature Envy or Inappropriate Intimacy because the toString() method is exposing internal details of the query (its string), and its caller makes a decision, instead of the query deciding for itself.

• Since search outnumbers add, anything we do to speed up search at add's expense will speed up the overall system. This suggests that we could process the catalog after the last add, in such a way as to speed up searches.

• The way we've set up the interaction, the catalog has no idea what the search will do. One way to speed up search would be to couple them more. Suppose queries were willing to tell the catalog "one of these words must appear in any item I'd potentially be willing to select." Then we could cache a map of words to candidate items and search many fewer items.

A. Only StringQueries go to the catalog; others are built out of the results of queries.

B. We definitely want to move to a Set type. Again, the trick will be a good preparation after the adds are done. We could prebuild a map from words (i.e., the StringQuery's query string) to sets of items; this would turn simple queries into a lookup instead of a scan.

C. Interpreter ”think of matchesIn() as the evaluation method, and the catalog as the context. The computation " bubbles up" the results of the query.

B. It's an example of Decorator (and Iterator, and probably others as well).

C. The biggest problem is that the enumerator implies we have to look at every entry. The other approaches are able to avoid this.