Case Study of Writing the Extensible Visitor Pattern

From APIDesign

Done: 3bfa995fae68

I liked this section, too. Practical, example-based ways of applying the concept learned in the book. Awesome.

I'd almost recommend that this and the previous section should be in their own part of the book. "Part IV: Experiences" or something.

Paragraph 2: "in the tool apt" doesn't make sense. If "apt" is the name of the tool, it needs to be set apart in quotes or in typeface.

"traversing hierarchies of heterogeneous data structures" (note the spelling of heterogeneous) is quite a chunk of text. Any way to make that a little less haughty-sounding?

--Dmkoelle 02:47, 23 April 2008 (UTC)

"would keep all kinds of compatibility, see expr, based on generics": what is "expr"? Looks like a link is missing.

Why are most of the classes in the visitor examples static?

In the visitor pattern, it is common for the method in the element classes (Plus, etc.) which takes a visitor instance to be named accept, not visit.

The "Old visitor used on new exceptions" message in the abstract Visitor doesn't make sense to me, perhaps "new elements" is what you meant.

Common Java code conventions advice against underscores in identifiers. Moreover, you talk about "Valid10" and "Visitor70" in the text. Please make this consistent, ideally by removing the underscores.

"exception subtype" should probably be "element subtype".

Perhaps I'm just missing something, but we fact that visitMinus visits the children elements by default looks wrong to me. The visitor pattern describes the visitor as an interface with no default behavior. The actual behavior is implemented by the visitor implementation. But here, you have made an arbitrary choice for the behavior (what if I want to visit the numbers in postorder?), and worse, only for a part of the tree.

"the client visitor that just called the method" looks unclear. How about "the Visitor which was passed to Expression.visit"?

--AndreiBadea 12:44, 23 April 2008 (UTC)