Me at JavaOne: Design Patterns Reconsidered
Speaking of talks, I will be presenting at JavaOne today (4:10 pm in Gateway 102/103) on “Design Patterns Reconsidered”. I’m about 80% excited and 20% terrified, which is a good mix for me. I’ve given this one in different forms a couple times and I know this will definitely be the best version of it I’ve ever done. If you’re interested in design patterns, stop on by.
Session abstract:
The design patterns movement launched a revolution in object-oriented design and provided a vocabulary for developers doing object-oriented development to communicate their ideas. However, in some cases, patterns used blindly can lead to awkward, confusing, or hard-to-maintain code. It is time for some common patterns used on the Java™ platform to be reconsidered so that we can derive the benefits from patterns while minimizing the concerns they can raise.
Design is a matter of balancing a variety of forces; patterns exist at the balance points between forces. In any particular scenario, those forces will not be balanced in the same way. Designers must then apply their knowledge of patterns and the product to find a unique instantiation of the pattern that optimally balances the forces at work.
This session re-evaluates key patterns such as Singleton, Template Method, Visitor, and Proxy. These patterns have downsides and do more harm than good in some cases. The presentation gives examples of each pattern in the Java development environment and examines them for clarity, testability, and flexibility. It discusses important problems and gives examples of alternative solutions, including ways in which Closures could be leveraged in a future version of the Java platform to alter these patterns.
Hi! My name is Alex Miller and I live in St. Louis. I write code for a living and currently work for 
I’m quite interested in your talk. Will you post your slides after the talk for us who can’t go to San Francisco? Thanks.
JavaOne usually makes all of the slides available after a couple weeks. Or drop me an email (see bottom left of this page).
I’ve got a problem that I was thinking of solving with Visitor. Under what circumstances do you consider Visitor to be a bad choice?
Hmm…I think if your data structure is being extended a lot you would need to revisit your visitor implementations frequently. What’s your hesitation?
I’m very curious, first, as to when Visitor would be a bad choice, like you mention in your blog article above.
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.
Hey Mark,
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.