Seems like a valid approach to me. I’ve actually done exactly this on more than one project with the Visitor pattern and it worked quite well. As you mention, it’s nice to be able to create different kinds of validation depending on need.

As for my particular case, I’ve created a way to serialize our data model out to plain text. We can’t use XStream or the like because I’m working with 6 year old legacy code that has — through its own internal architecture — its own idioms and quirks.

When we deserialize this data back into our application, the entire data structure will be in memory but not yet committed to the database. It’s at this point that I would like to validate it with Visitor.

Our model doesn’t change much, certainly not as much as the business rules do. That’s one of the intents of Visitor, to separate the ever-changing business rules from the infrequently changed model.

I’m imagining, too, we can put one validation rule in each Visitor and vary which visitors are run for our customers. This would provide the flexibility to run one type of validation for one customer and an entirely different type of validation for another customer that has different business requirements.

I know it will work because I’ve prototyped it and I think it would be a very elegant solution.

Would you validate a model in a different way? Would this use of Visitor cause more harm than good, as you allude to be true for some cases?

I wish I could have seen your talk! Maybe next year I’ll get a chance to go to JavaOne.