Part 3 : Pushing the Code Further

Part 3: Pushing the Code Further

Part 3 contains some ideas for pushing the code further, exercises for you to do on your own.

Exercise 108 Remaining Smells.

What smells remain in your code?

I've noticed that velocity updates are handled differently than other updates; I still have that rollover calculation in Card that I never liked ; there are some bits of duplication remaining; and I continue to think a separate model layer would help. In some ways, the current design is near a local maximum ”it's becoming reasonable for a design that keeps the model and view together, but we need to go off this hill a little to climb a bigger peak. (The problem is that the code still doesn't communicate something we know: Some parts of this program are affected by its user interface, but others aren't. This is an example of Divergent Change.)

If you're not familiar with the model/view or model/view/controller idea, you may want to do some background reading: See the Observer pattern in Gamma et al.'s Design Patterns , the TableModel (or other models) in the Java libraries, or the HotDraw framework (described at c2.com/cgi?CrcCards and www.c2.com/doc/crc/draw.html ).

We might start by creating a Card model. Right away we'll face a decision: Should it contain the model for the title, or should we use the one Java provides in the TextField? If we let the Card have its own model, we'll have to be careful not to cause a notification loop (where the Card notifies the TextField of a change, so it tells the Card, which notifies the TextField, and so on). If we use the Java-provided model, our hookup will be a little trickier.

Exercise 109 Separate Model.	Make sure to save the old version before you start these changes. Apply Duplicate Observed Data to split the Card class into a Card and a CardView. (Note that this is not a trivial refactoring. Don't be surprised if this exercise takes a whole session.) Apply Duplicate Observed Data to Background. Feel free to make use of the DefaultListModel, which builds in notification. You can get very fine-grained notification about list changes, but start by just rebuilding the whole list when told it has changed. Note that Card's location and selection status are stored in the view. (Is this the right place?) If you try to regenerate views, you must make sure to track this information. Apply Duplicate Observed Data to Plan. Divide the program into two separate packages : one for all the models, the other for views. Let view classes depend on the model classes, but not the other way around. (You may find you need to create separate test classes for models and views.) This was a lot of work. Is it an improvement? What future changes will be easier because we've done this? (If it's not an improvement, restore your old version.) See Appendix A for solutions.
Exercise 110 An Optimization. (Challenging).	The simplest form of notification looks like this: public void setTitle(String title) { this.title = title; notify(); } A more sophisticated implementation is: public void setTitle(String title) { if (this.title.equals(title)) return; this.title = title; notify(); } When is this a performance optimization? What other purpose does it serve? See Appendix A for solutions.
Exercise 111 New Features.	Consider new features that might be added. How robust is our implementation in the face of these? New cards should be placed top to bottom and left to right instead of diagonally. We'd like buttons for the manager or team roles. All colors and sizes should be made into preferences. Plan analysis should detect too many points in an iteration. Save and restore your work via some persistence mechanism. Allow people on multiple sites to work on the plan at the same time. What other features might you add?
Exercise 112 Test-Driven Development.	Reimplement this code from scratch, using the test-first approach. Don't look at the old version while you develop the new one. What do you see?

The code for this exercise was not originally written in a test-first way. The experiences of people who do test-driven development indicate that a different design often emerges than the one they expected. Did that happen for you? Is the code better? Are the tests better? How much did the original design influence you?

Exercise 113 Lessons from Test-Driven Development.

Assuming your test-driven code is different from the code you were working with before, could you refactor the old code until it matches the new code? Are there refactorings you would need that are not in any book? What smells could guide you so that you would naturally refactor in that direction? Does this teach you anything about refactoring, or about test-driven development?