Errata

From Productiveprogrammer

Jump to: navigation, search

Contents

[edit] Book Errata & Improvements

(by page of occurrence)

[edit] I:84 ( DRY: Impedance Mismatch )

Java Bean Generator Code: Using Groovys Triple Quotation Marks and no tabs would have made the write_properties method much easier to read. Imports could have be deduced from the type mapping.

[edit] E:85 ( DRY: Impedance Mismatch )

The Java class shown is no DAO but a Java Bean Pojo. DAO is a pattern for encapsulating the data access layer. It would be nice having a simple ibatis-CRUD-DAO generated as well.

[edit] I:145 (Angry Monkeys)

Underscored test method names. It would have been great if a reference to this section was given at the first appearance of these test method names in the book. They troubled me up to this page. There is the great TestDox plugin for IntelliJ IDEA for generating testcases and methods and having an outline view which renders camel case method names to space separated sentences.

[edit] E:150 (Java & Reflection)

catching Throwable is bad practice as this also silently catches Errors (like OutOfMemory and other critical stuff). Catching Exception is enough.

[edit] I:153 (Fluent interfaces)

Recipe.for "Spicey bread"
.mix 200.grams.of Flour 
.with 1.lb.of Nutmeg

Would also have been a nice syntax.

[edit] I:154 (Fluent Interfaces)

Test: This is hardly a unit test, rather an integration test as the ingredients are not tested separately. Edge cases are also missing. except for the "add"-setup the "expected" array is not used for any expectation assertions.

[edit] I: 156 (SLAP - Composed Method)

A reference to Kent's Implementation Patterns would have been nice. As this is the more recent book on the topic. There he elaborates quit a lot on this pattern. As well as symmetry which is also a principle in his (value-principle-pattern system).

E: calling c.close on the connection in case of an Exception (c is still null) will yield a NPE in the finally block

[edit] E:185 (Keeping Behavior in Code)

"This is easier to read because it has much less XML-based noise in it, like curly braces"

Probably meaning: like angled brackets.

On the same page, when talking about builders, it says that Ruby builders were inspired by Groovy builders. Wasn't it the other way around? (No it wasn't)

Personal tools