The Visitor Pattern – Part 4

The interface approach introduced in Part 2 of this series and extended in Part 3 did cover most of our needs. But there is nothing that can’t be done better with the right tools.

I’ve been using this approach for a couple of years and it made my life a lot easier. You need an export as DXF? No problem! Displaying in OpenGL? I’ll write a new visitor!

Writing the additional interfaces was easy done with the help of a customized code template, so that has never been a pain. The only thing that bothered me over time was that I could only apply the Visitor Pattern to classes I have control of. I just wasn’t able to visit, say, all the components of a TForm in a descent fashion (i.e. not queueing if component is something then <typecast>).

While digging through the new features of Delphi 2010 I discovered a solution which is as clean, lean, flexible and elegant as it could be. A little RTTI and some decent naming convention did the trick. Here is the code:

And here is a visitor capable of handling some VCL controls on a form together with an example of its usage:

If you need to visit some class, just introduce a new method with a suitable name and signature and you are done. No new interfaces, no fiddling around with classes. It just works right out of the box.

I’m still visualizing some possible scenarios where this approach can be useful, too. Stay tuned.

Author: Uwe Raabe

Addicted to Pascal/Delphi since the late 70's

4 thoughts on “The Visitor Pattern – Part 4”

  1. Hi Uwe,

    First of all, thank you for these great articles. I really appreciate your manner of thinking. This elegant way of programming could be help me to implement validator components like a “universal” solution to check user entries even under third party tools like DevExpress Editors. But maybe, this is already in your vision for some possible scenarios. I would appreciate to read more on this approach.

    Thank you for your great contributions.


  2. Hi,
    you have published a very good series of articles.
    The implementation you suggested in the last post is already known in the java world because of the java reflection is available on that platform since a long time.
    Thanks codegear to have introduced the extended RTTI. This is an example of how useful can be new language features that are already available in other languages in order to leverage designs and patterns in delphi.

    Did you consider the performance penalty of using the RTTI instead of the other implementation?

    Stefano Moratto

  3. Yes, enhanced RTTI introduced in Delphi 2010 is great.
    But what you did has been possible “forever”

    The VisitXXX methods just have to be published. (Did you ever wonder how DUnit can show and call all the methods you implement in a test case?)

    1. Indeed, I missed the published thingy with that MethodAddress approach completely. Thanks for pointing that out.
      Oh, I added some formatting to make your code example look better 🙂

Comments are closed.