How is walking the list of machines a case of Feature Envy or Inappropriate Intimacy?
Address this by extracting a new class. Make sure it has a report() method.
See Appendix A for solutions.
Exercise 36 Middle Man. (Challenging).
Consider these classes:
(This code has been greatly simplified; the queue wasn't originally storing strings.)
Queue.java
import java.util.ArrayList; public class Queue { ArrayList delegate = new ArrayList(); public Queue() {} public void addRear(String s) {delegate.add(s);} public int getSize() {return delegate.size();} public String removeFront() { String result = delegate.get(0).toString(); delegate.remove(0); return result; } }
QueueTest.java (selection)
public void testQ() { Queue q = new Queue(); q.addRear("E1"); q.addRear("E2"); assertEquals("E1", q.removeFront()); assertEquals("E2", q.removeFront()); assertEquals(0, q.getSize()); }
Remove Middle Man so that the queue is no longer a middle man for the ArrayList. Is this an improvement?
Put the Middle Man back in via Hide Delegate .
See Appendix A for solutions.
Exercise 37 Cart. (Challenging).
Consider these classes:
Here is Cart.cost():
public int cost() { int total = 0; for (int i=0; i < purchases.size(); i++) { Purchase p = (Purchase) purchases.elementAt(i); total += p.item().cost + p.shipping().cost; } return total; }
Write the implied classes (and tests). The maxDays() method computes the largest number of days for any ShippingOption in the purchase.
Apply Hide Delegate so Cart accesses only Purchase directly.
Hide Delegate causes the Middle Man (Purchase) class to have a wider interface; that is, it exposes more methods . But applying that refactoring can open up a way to make the interface narrower. Explain this apparent contradiction.
Use this line of reasoning to narrow the Purchase interface.
Notice that the primitive int type is used to represent money. Would it be easier to introduce a Money class before or after the delegate changes?
See Appendix A for solutions.
Exercise 38 Trees in Swing. (Challenging).
In Swing, JTree is in the javax.swing package, and TreeModel and DefaultTreeModel are in the javax.swing.tree package. (The table classes have a similar organization.)
Explain how the TreeModel interface breaks the dependency between JTree and DefaultTreeModel.
Explain how there are still dependencies at the package level.
Suppose each package corresponds to a library (this is an oversimplification). Explain a way to break the package dependency so that JTree could be shipped in a library independent of DefaultTreeModel.
Systems today ship with so much disk space; why should anybody worry about library dependencies?
See Appendix A for solutions. 
