Chapter 3. Measured Smells

EXERCISE 3. Comments

B. Can everything important about the code be communicated using the code alone? Or do comments have a place? Code can usually communicate the how of something fairly well; it's not always able to communicate the why as well; and it's almost impossible to communicate the why not. When code becomes published for others, some people find it important to include JavaDoc comments to provide extra explanation.

EXERCISE 4. Long Method

A. Block 1: out.println("FACTORY REPORT\n"); Block 2: From there until out.print ("Robot"); Block 3: From out.print ("Robot"); through write("\n"); Block 4: out.println("=======\n"); You might have chosen a slightly different set of blocks. B. public static void report ( PrintStream out, List machines, Robot robot) { reportHeader(out); reportMachines(out, machines); reportRobot(out, robot); reportFooter(out); } We wouldn't stop here, but this would be a good first step. (We could either move toward a Report class or toward putting report() methods on the Machine and Robot classes.) C. Does it make sense to extract a one-line method? Yes, if it communicates better.

EXERCISE 5. Large Class

A. It's doing a lot of things; some are inherited, but it seems to have a variety of responsibilities. B. Go through the methods listed, and categorize them into 5 to 10 major areas of responsibility. My list is as follows (yours will vary): Columns Editing Rendering Model Selection Appearance Notification Other C. It might be possible to generalize addresses so there wouldn't be so much need to have symmetrical row and column functions. It's possible to pull out helper classes that would own some corner of the responsibility. Some of the methods appear simply to consult the table or column model for their answer. The appearance properties could be managed separately or through a simpler interface. D. I'm not a Smalltalk expert, but I think a few things contribute to the difference: Smalltalk's dynamic typing lets generic methods be defined more easily. Smalltalk has been around longer, and more methods have worked their way in. Smalltalk's interpreted (and more open) environment has encouraged more experimentation.

EXERCISE 6. Long Parameter List

A. x/y/width/height sounds like a Rectangle object. value/extent sounds like a range. (Notice that the limit parameters use min and max rather than a second range; the whole thing might be cleaner if there were a separate Range class.) x1/y1/x2/y2 sounds like another Rectangle. B. In some ways, it's a reflection of an attempt to make a class more generic—pass in everything it could work with. Things like graphics tend to want to be stateless, and using lots of parameters can help them do that. C. There are many occurrences of row/column together; that makes me wonder if the object would be simplified using some sort of locator instead. It would probably simplify selection, and it might address challenges such as cells that span two rows.

EXERCISE 7. Smells and Refactorings	A. Comments B. Large Class C. Long Method D. Long Parameter List B Duplicate Observed Data B Extract Class B Extract Interface A or C Extract Method B Extract Subclass A Introduce Assertion D Introduce Parameter Object D Preserve Whole Object A Rename Method D Replace Parameter with Method
A2:	A. Which do you see or create most? Everybody's list will be different. Long Method and (Unhelpful) Comment are the two I see most. Of those, Long Method is probably the one I self-inflict the most. B. For these measured smells, you can give yourself a cutoff number that tells you to review what you're doing. For example, I check twice if a method exceeds about seven lines, and I question any comments in the body of a method. Define your own triggers.