In Python, with iterators, the Visitor design pattern is useless. And a strongly-ingrained habit. Which I'm trying to break.
Here's a common Visitor approach:
class Visitor: def __init__( self ): ... def visit( self, some_target_thing ): ... def all_done( self ): ... v = Visitor() for thing in some_iterator(): v.visit(thing) v.all_done()
If we refactor the for statement into the Visitor, then it's just a Command or something.
Here's the refactored Iterating Visitor:
class Command: def __init__( self ): ... def process_all( self, iterable ): for thing in iterable: self.visit( thing ) def visit( self, thing ): ... def all_done( self ): ... c=Command() c.process_all( some_iterator() ) c.all_done()
The one possible objection is this: "What if our data structure is so hellishly complex that we can't reduce it to a simple iterator?"
That's perfectly silly. Any hyper-complex algorithm to walk any hyper-complex data structure, no matter how hyper complex, can always be recast into a generator function which uses yield to iterate over the objects.
Once we start down this road, we can generally simplify processing into a kind of Command that looks something like this.
class Command: def __init__( self ): ... def run( self ): for thing in self.iterable: .... c= Command() c.iterable= some_iterator() c.run()
I find that this interface is somewhat easier to deal with when composing large commands from individual small commands. It follows a Create-Configure-Run pattern that seems to work out well. I just wish I would start with this rather than start with a Visitor, refactor, and end up with this.