Path 1: Catalog.itemsMatching(query) We'll work with option (a) for now. For our first cut, we'll start with a Catalog and just use strings for queries and items. Here's a test: Catalog catalog; public void setUp() { catalog = new Catalog(); catalog.add("Hammer 10 lb"); catalog.add("shirt XL blue"); catalog.add("shirt L green"); catalog.add("Halloween candle orange"); catalog.add("Halloween candy gum"); } public void testSimpleQuery() { List result = catalog.itemsMatching("shirt"); AssertEquals(2, list.size()); } | Exercise 78 Catalog. | Write a simple Catalog class with the two implied methods . | | Exercise 79 Query. | Extract the current query string into a Query class. |
Your Catalog class probably has a line something like if (item.indexOf(query) != -1) Modify this to if (item.indexOf(query.toString()) != -1) as being the least change. | Exercise 80 Trading Off Smells. | Explain how this adds a small case of Feature Envy or Inappropriate Intimacy in the process of cleaning up a little Primitive Obsession.  See Appendix A for solutions. | | Exercise 81 Move to Query. | Extract Method on item.contains(query.toString()) , then Move Method to put the matching behavior on the query. (In the end, you'll call query.matches(item) .) |
We'd like to expand our queries to support more complex queries. "Halloween OR shirt" should find several items. In this exercise, we won't worry about parsing; instead, assume our queries will be composites like that shown in Figure 15.1. We'll call the top node in the figure an OrQuery, and the others will be called StringQuery. Both of these will be subclasses of Query. Figure 15.1. A Query in the Form of a Composite  | Exercise 82 StringQuery and Query. | Extract Superclass (or subclass, depending how you look at it:), so StringQuery becomes a subclass of Query. |
Sometimes you'll hear people speaking of a refactoring making room for new code. This is an example of that: We're making room for an OrQuery subclass. You could come at it the other way ”introducing the OrQuery and then removing the duplication. | Exercise 83 OrQuery. | Create an OrQuery class that meets this test: Query query = new OrQuery (new StringQuery("shirt"), new StringQuery("Halloween")); list = catalog.itemsMatching(query); assertEquals(4, list.size()); |
One way to think of this approach is as an example of the Strategy pattern. The catalog is the context, and the different queries all implement different algorithms for matching. (You might also detect a Composite pattern in the way the queries are constructed .) | Exercise 84 Performance. (Challenging). | Suppose a profile showed that our queries are too slow. Suppose further that we find our queries are used thousands of times per day in a batch, while additions are done only once per day. We also find that any given word is unlikely to appear in more than a small fraction of the items. What ways can you suggest to speed up performance? See Appendix A for solutions. |
P ERFORMANCE We want our systems to have good performance, good response time, and so on, so we sometimes worry about performance of our code. It's a reasonable concern; some refactorings can slow down the system by introducing more objects, more method calls, and and the like. Other factors counteract this: -
Most untuned code has only a few hot spots where performance matters; we can tune them later. -
A clean design can open the way for deep understanding that makes huge improvements possible. -
It's easier to tune a clean design. When there are performance worries, there are several ways out: -
Do a thought experiment to see a path toward a performance boost. (For example, we may have linear-search collection, but know that we can index it for higher performance if it turns out we need to.) -
Look for an existence proof that there's a faster way. -
Try a spike ”pull out the essential algorithm and play with it separately. Once we know there is a way to speed up, we have an ace in the hole; we needn't feel compelled to implement it until it's required. |
 |
