14

When setting out good design, which would you choose, extension methods or the visitor pattern?.

Which is easier to design for, when should you use an extension method over a visitor pattern and vice verso?

Is there any good valid reason to use an extension method over a visitor class, apart from syntactical sugar to aid in program readability?

How would you design for a system that incorporates extension methods, would you classify them in a UML diagram?

namespace ExtensionMethods { public static class MyExtensions { public static int WordCount(this String str) { return str.Split(new char[] { ' ', '.', '?' }, StringSplitOptions.RemoveEmptyEntries).Length; } } }

I may have the wrong pattern, it looks like a visitor pattern from the code above. So I think my comparison holds up.

Some code, I would say that the extension method looks like a visitor pattern. 

using System; using System.Collections.Generic; using System.Linq; using System.Text; namespace ConsoleApplication1 { #region Interfaces public interface IFred { string Data { get; set; } string doSomething(); } public interface IBob { string Data { get; set; } } #endregion #region fred stuff public partial class Fred : IFred { public string doSomething() { return this.Data + " is really cool"; } public string Value() { throw new NotImplementedException(); } } public partial class Fred { public string Data { get; set; } } #endregion #region bob stuff public class BobData : IBob { public string Data { get; set; } } public class BobData2 : IBob { private string pData; public string Data { get { return pData + " and then some!"; } set { pData = value; } } } public class BobVisitor { public string dosomething(IBob bobData) { Console.WriteLine(bobData.Data); return "ok"; } public string dosomethingOnlyToBob(BobData bobData) { Console.WriteLine("hello bob version 1"); return "ok"; } public string dosomethingOnlyToBob2(BobData2 bobData) { Console.WriteLine("hello bob version 2"); return "ok"; } } #endregion public static class Visitor { public static string visit(this IBob bobObj) { Console.WriteLine(bobObj.Data); return "ok"; } public static string visit(this IFred fredObj) { Console.WriteLine(fredObj.Data); return "ok"; } } class Program { static void Main(string[] args) { //Another way of abstracting methods from data, using Partial Classes. var fredObj = new Fred(); fredObj.Data = "fred data"; fredObj.doSomething(); //Create the bob classes version 1 and 2 var bobObj = new BobData(); bobObj.Data = "bob data"; var bob2Obj = new BobData2(); bob2Obj.Data = "bob 2 data"; //using the bobVisitor Class var bobVisitor = new BobVisitor(); bobVisitor.dosomething(bobObj); bobVisitor.dosomething(bob2Obj); bobVisitor.dosomethingOnlyToBob(bobObj); bobVisitor.dosomethingOnlyToBob2(bob2Obj); //using the extension methods in the extension class bobObj.visit(); fredObj.visit(); Console.Read(); } } }
Improve this question
3
  • 2
    I think that writing an extension method and the visitor pattern are inherently solving the same problem. But with the Visitor pattern you can completely separate the logic from the class. Extension method is kind of adding a method onto the class itself. Commented Aug 4, 2011 at 3:56
  • Visitors do separate data from methods. I think that the syntax sugar that extension method classes add, obfuscate to what they really are. I was tempted to call them decorators but on closer examination, they act upon the whole class, check out the syntax. Commented Aug 4, 2011 at 12:19
  • They don't really add anything to the class. Just a bit of sugary magic. Commented Aug 4, 2011 at 12:20

2 Answers 2

Reset to default
9

You probably should be comparing the visitor pattern against the template method pattern, as those are two things you can compare and contrast.

Comparing the visitor pattern with extension methods is like comparing a car with a bicycle sprocket.

In any case, extension methods are useful anywhere a non virtual method is useful, with the added bonus that you don't need to own the type to define an extension method.

Both the template method and visitor pattern are design patterns intended to operate over trees of objects. The "classic" definition of both requires a virtual method in each "node type" in the object tree. However, it is possible to implement both using non virtual methods if necessary. There are some limitations, such as access to private and protected members, but ignoring that, either pattern can be implemented with extension methods.

The template method pattern works by adding a virtual method for an operation to each type in the object tree, with "aggregate nodes" calling into to the method on their contained nodes.

An example might be a "print" method for an expression tree.

public class Node { abstract void print(); } public class AddExpression : Node { Node Left; Node Right; virtual void print() { Left.Print(); Console.WriteLine("+"); Right.Print(); } }

This has a major benefit, in that adding new node types only requires incremental effort. Only the new types need to be changed. It has a drawback, however, in that adding new operations requires editing every single type.

The visitor pattern generalizes template methods into a single method called accept that takes a visitor object as a parameter. It looks something like:

interface Visitor { void VisitAdd(AddExpression e); void VisitSubtract(SubtractExpression e); } abstract class Node { abstract void Accept(Visitor v); } class AddExpression : Node { //... virtual void Accept(Visitor v) { Left.Accept(v); v.VisitAdd(this); Right.Accept(v); } }

This has the opposite tradeoffs. Adding new operations only requires writing one new class, but adding a new type requires editing every operation.

The classic advice is to use template method when the operations are (relatively fixed) but new object types can be added frequently. Similarly, visitors should be used when the object typed are fixed, but new operations can be added frequently,

If both change equally, then your decision should be based on balancing:

  1. Clarity (template methods are easier to understand, and avoid the overhead of double dispatch).
  2. Reuse (visitors factor common traversal code into a single place).
Improve this answer
Sign up to request clarification or add additional context in comments.

20 Comments

The tree thing is correct when using a visitor pattern in general. But I am not talking about finite state machines or anthing like that. First I think we need to categorize what an Extension method is, I for one believe its a visitor pattern or maybe a decorator. I would call it a visitor, just by the very design of the class. When used however, the syntax sugar hides what it is.
Huh? An extension method is not a design pattern. It's lower level than a dedign pattern. It's just a type of method. The same way a "for loop" is not a pattern.
A for loop is a pattern. Google it.
The iterator pattern is a design pattern... a for loop is a mechanism for one way of implementing it...
@Scott, some languages opt out of the for loop mechanism, but they to have a need to use a system where they iterate over a series of items in a list. This I would say is a design pattern. The implementation of a for loop should not be confused with the mechanism. I use the Iterator Pattern from the classic Gof as an example of a pattern that is used in OO languages. As you know you could use Array.ForEach to iterate over an array. The actual implementation is hidden away, but the concept is still there, as a pattern.
|
-1

Extension methods aren't a pattern. They are just some language syntax which makes code easier to read.

Visitor pattern is an entire different beast. I don't really know why you are comparing the two.

Improve this answer

15 Comments

They are a design pattern, just that the syntax sugar hides what they really are.
I down voted on the fact that an Extension does form a pattern. It acts upon a passed in object. The pattern repeats itself, that is what a pattern is. You can reuse the pattern over and over again. The fact that the environment sugar coats it nicely, to make such lovelys as Linq look and feel like an SQL type language, does not deter from the fact that an Extension method is a pattern. If you honestly look at Extension methods as just "syntax sugar", then I beg you to look at them again and re-evaluate your opinion.
I also down voted on the fact of the brevity of the answer, and the opinion was given without any thought to the question being asked. It makes one ask if the intention was just to sound smart, and not to answer the question at all. It is so easier to be mysterious and laconic than to be polite, poetic and with some style. It takes time to care, it takes minutes not to give a sh*t.
@Phil, so far there hasn't been a response to my question which I feel has answered it. If you have nothing but troll behavior about you I would kindly ask you to leave me be.
@WeeNeedAnswers, Extension methods are nothing other than static methods. Any "pattern" that can be done with extension methods can be done using static methods. Furthermore, extension methods are a language feature, not a pattern. A design pattern is a general solution to a common problem and is (mostly) language agnostic. Extension methods are just a different way of calling static methods in 1 particular language. The brevity of my answer reflects well the lack of focus of the question. If I asked "Please compare a car and a phone", I wouldn't expect any more than "They are different"
|

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.