I usually don’t talk about architecture on this blog*, but tonight I’m going to make an exception. I’ve been knee deep in performance work for Flex Builder 3, and so far it’s been pretty easy going. Today was not one of those days. Today was the kind of day that makes me want to quit and snowboard full time. Well, almost.

So, here’s what I ran into…I’ll break it down into easy bullet points:

1. Don’t use the Visitor pattern, and if you must, make sure you do it right.
2. When defining a public API, make sure every element in the provided API is useful.
3. int arg0 is not an acceptable symbol name, and it’s useless without comments. Don’t do this unless you want me to yell at you.

Ok, so point 1 is a bit contentious but I stand by it. I’ve seen too many implementations of the Visitor pattern that require you to have intimate knowledge of the structure you are traversing. 90% of the time I implement a Visitor, I end up having to keep track of context, depth and in extreme cases fragments of data that logically belong grouped together. As a client, I shouldn’t need to do any of this because, among other things, I am not supposed to know how deep I may be in the structure. On an unrelated note, I’ve also seen 20+ visitors on a large tree dragging performance down. Visitors seem to make engineers lazy: “Eh, it’s a Visitor…I’ll just write another one…that’s what it’s designed for!” For gods sake, consolidate them if you can: who knows how large the object you are visiting may be?

So, if you insist on building a Visitor interface, please make sure it allows for context, please make sure there aren’t better patterns to use and please don’t make me keep a stack to find information that should have just been passed into the same method. Again, I may yell at you.

Wow, I’m feeling a bit better. On to point 2: Let’s say I have a Visitor that passed an object as a parameter. That object is not useful if all the fields are private and no accessors are provided. You have just made your Visitor useless…good job! The important takeaway here is that every class you reference in an API should be accessible and well thought out. We do that in Flex Builder: every class in the public API of our Code Model, and every API was scrubbed to avoid issues like this. If you want people to use it, make it useful.

Alright, point 3 is so obvious I’m not going to waste keystrokes on it. I’ll just say it again: arg0, arg1 or even arg12 are never valid symbol names. Never!

Anyway, time to head back into the code. This should be fun…

*I don’t talk about architecture mainly because there are hundreds of great resources for it (far better than this site)… and it’s always a contentious issue.