| Exercise 36. Middle Man | A. Is a removed middle man an improvement? Not to my eyes ”we've reduced the clarity of our code if nothing else. If the event handler is given an ArrayList, it implies a lot more freedom to change it. With the Queue class, we know it's a queue: we can see exactly where the delegate gets touched. Without the Queue class, we have to look across every event handler to be sure that nonqueue operations aren't used. |
| Exercise 38. Trees in Swing | A. TreeModel breaks the class dependency because JTree and DefaultTreeModel both depend on TreeModel, but JTree doesn't depend on DefaultTreeModel. B. Package dependency still exists because JTree is in the javax.swing package, and it is depending on a class in the javax.swing.tree package. (Think of a package dependency as implying that everything in the package is brought in along with everything it depends on. At the package level, JTree depends both on interfaces and on concrete classes.) C. There are two approaches we can take to break the package dependency. One approach would be to move the TreeModel into the package with JTree. This leaves javax.swing.tree dependent on javax.swing, but not vice versa. That's an improvement because, if you implemented your own tree model class, you wouldn't need any of the javax.swing.tree package to be present. It's still troubling, though, in that, if you want to create a tree model that doesn't need a JTree to display it, you'd still have that dependency at the package level. A second approach would be to pull the TreeModel into its own package (depending on nothing). Let javax.swing depend on the package, and let javax.swing.tree depend on the package, but do not let them depend on each other. Class loading doesn't actually load one package at a time, so package dependency is something of an intellectual construct. But I find it helpful to consider these dependencies, as they can reveal places where things that should be stable rely on things that change , rather than vice versa. (See Robert Martin's book, Agile Software Development: Principles, Patterns, and Practices , for more on dependency rules.) D. In a world of abundant disk space, it matters for two reasons: First, extra dependencies reveal places where we haven't worked our way to understanding the minimum our classes need to do. Second, not everything is a desktop system with a huge disk; look at the challenges J2ME has had in getting to a minimum-weight library. For an extra exercise, consider what classes are brought in if you want the minimum to support Object. (Try at both the class and package levels.) |
