Comments on: Live patterns: Switching to the visitor design pattern http://davidrabinowitz.com/en/2009/05/29/live-patterns-switching-to-the-visitor-design-pattern/ Tue, 20 Jul 2010 11:16:08 +0000 hourly 1 http://wordpress.org/?v=3.0.1 By: Frood http://davidrabinowitz.com/en/2009/05/29/live-patterns-switching-to-the-visitor-design-pattern/#comment-9 Frood Wed, 16 Jun 2010 12:33:40 +0000 http://www.davidrabinowitz.com/en/?p=31#comment-9 @Dimitris: The Visitor pattern buys you a bit more than that: You can put the code into the layer it rightfully belongs to. So, the visitors concerning UI go to the UI code and the ones concerning business logic go to the business code etc. Without visitors you have to either put the code into the objects themselves, thus blurring the layers, or replicate the objects inside a layer, being cumbersome and error-prone. Besides, in case of hierarchies you can use walkers to traverse object trees, in which visitors act as a kind of beefed-up lambda expressions. Very handy @Dimitris:
The Visitor pattern buys you a bit more than that: You can put the code into the layer it rightfully belongs to. So, the visitors concerning UI go to the UI code and the ones concerning business logic go to the business code etc. Without visitors you have to either put the code into the objects themselves, thus blurring the layers, or replicate the objects inside a layer, being cumbersome and error-prone.
Besides, in case of hierarchies you can use walkers to traverse object trees, in which visitors act as a kind of beefed-up lambda expressions. Very handy

]]> By: Dimitris Andreou http://davidrabinowitz.com/en/2009/05/29/live-patterns-switching-to-the-visitor-design-pattern/#comment-8 Dimitris Andreou Sat, 30 May 2009 19:26:43 +0000 http://www.davidrabinowitz.com/en/?p=31#comment-8 Well, I don't think this is the life-saver you seem to be describing... What visitor buys you here is merely the fact that you don't have to put an abstract method plus implementations for each distinct type-based desicion (bloating a single file), but create those implementations externally (out of the itinerary source files). I.e. you just managed to avoid putting the type-based code in the types themselves, but somewhere else. Good for you. Where would we be without patterns! :) Btw, Scala supports the switch you describe (where the compiler notifies you of missed cases). Well, I don’t think this is the life-saver you seem to be describing…

What visitor buys you here is merely the fact that you don’t have to put an abstract method plus implementations for each distinct type-based desicion (bloating a single file), but create those implementations externally (out of the itinerary source files). I.e. you just managed to avoid putting the type-based code in the types themselves, but somewhere else. Good for you. Where would we be without patterns! :)

Btw, Scala supports the switch you describe (where the compiler notifies you of missed cases).

]]> By: Omar http://davidrabinowitz.com/en/2009/05/29/live-patterns-switching-to-the-visitor-design-pattern/#comment-7 Omar Sat, 30 May 2009 16:09:56 +0000 http://www.davidrabinowitz.com/en/?p=31#comment-7 Ok, I think you make your point about how much cumbersome could be the code with the first two sniplets. Could you please ilustrate the visitor design patter with an example of your own? The link in the wikipedia it's ok, but don't be cheap and complete your post. ;) Ok, I think you make your point about how much cumbersome could be the code with the first two sniplets. Could you please ilustrate the visitor design patter with an example of your own? The link in the wikipedia it’s ok, but don’t be cheap and complete your post. ;)

]]>