COMP 310
Fall 2010

Lec20:  Extended Visitor Design Pattern

Home  Info  Owlspace  Resources

finishing up from last lecture...

Motivations

Consider these two notions that we've been playing around with for the last few lectures:

Why not directly express the visitors and hosts in those terms?

 

The Key Characteristic of the Visitor Design Pattern

Let's look first at what is at the heart of the traditional Visitor Design Pattern:

Standard Visitors

But what's really going on here?   The key issue is the invariant above.   But, nowhere does it say that the identifier that matches the case to the host must be part of the name of the method!

Why couldn't that identifier be an input parameter to the case method?   After all, the host knows unequivocally what that value is!

Generalized Visitors

Let's look at an actual implementation of this "Extended Visitor Design Pattern":

Click for full size image
Extended Visitors

In this implementation, the ID that matches the host to its case is a String.   Internally, the ExtVisitor visitor implemenation of the IExtVisitor.caseAt(...) method uses a Java Map object (equivalent to a Python dictionary -- an implemenation of Map called Hashtable is actually used) to look up the matching IExtVisitorCmd command given an ID value.   The visitor then delegates the caseAt call to matching command or to the default command if no match was found.

The demo code dynamically generates the host and command instances using anonymous inner classes that close over their required parameters.

The "name" field in the ExtVisitor is only there so that the class's toString() method can return a unique String representation of the visitor that can be easily recognized in the drop list.  A normal implemenation of an extended visitor would not need such a field, i.e. it is totally extraneous to the extended visitor concept.

For the theoretically minded:  This implementation is analagous to the virtual method table that is used to implement polymorphic method dispatching in OO languages.

 

Download a demo of the above implemenation:

Be sure to try all the multitude of permutations that are possible with this simple demo!

Note:  This demo allows run-time modifications of the visitor algorithms for illustration purposes.   In a real-life situation, where the possibility of malicious hacking exists, this feature might be removed to increase the security of the system.  The ability to change the commands at run-time is not part of the fundamental notions of the extended visitor and is something that one would only include in scenarios where dynamic re-programming of the system is required.

 

Comparing the standard and extended visitors

Regular Visitor Design Pattern:

Extended Visitor Design Pattern:

 

Please read the student-written presentation of the extended visitor pattern.

 

Musings on the Visitor Pattern

Here's an interesting question:   Which is more "secure", the traditional Vistor pattern or the Extended Visitor pattern?

A general rule-of-thumb is that the more flexible and extensible a system is, the less secure it will be come.  But is that true here?

(Important note:  The following discussion is presented without formal proof and should be taken as thought-provoking and perhaps argument-provoking "musings".   No representation is being made as to the absolute validity of these musings.)

Consider the issue of trying to "spoof" a host, that is, to imitate being a host to get a particular visitor to run and perhaps reveal some hidden secret information inside the algorithm:

With a traditional Visitor pattern, the visitor has public methods corresponding to all its supported hosts (cases).  It's a simple matter to discover the names of those methods and to pose as a legitimate host calling the desired method.   The visitor is none the wiser and proceeds as normal, revealing its secrets along the way.  

With an extended Visitor pattern however, looking at the public methods of the visitor tells you nothing about the hosts that it supports.   Nowhere does a host expose its ID value to the public.    The ID for a particular host could be a string containing the complete works of Shakespeare!   Any other ID used would only result in the default behavior of the visitor.   In fact, the ID passed to the visitor could even be encrypted for even more security.   Here is a case where greater flexibility and extensibility actually leads to greater security, perhaps because the space of hosts and ID's has gone from a small, finite size to practically infinite. 

What about the other way around, that is, spoofing the visitor to trick a host?

Here the issue is perhaps less clear.  Fundamentally, a host has to have public methods to support the visitor's algorithm.  This is the same in either the traditional or extended visitor pattern so there is no change in the ability to secure the host between the two techniques.    If the hosts' public methods lead to an insecure front to the public world, the type of visitors used will not change that fact.  

However, let's consider the case where, by some means, say by requiring a precise ordering of the calls to the host's methods, the public face security of the host is reasonable.   Which is the effect of the different types of visitors in this scenario?   Once again, with a traditional visitor, it is easy to get the host to execute the malicious code by simply overriding the known corresponding case method.   The extended visitor gets the ID value when the host attempts to execute the visitor, so the advantage of not being able to guess the ID goes away here.   But that could be easily defeated by using an encrypted ID value that only a legitimate visitor could decrypt and use properly.   Definitely less of a clear advantage than the "spoof the host" scenario, but still the advantage once again goes to the extended visitor.

 

 


© 2010 by Stephen Wong and Scott Rixner