Question

Currently I have some code like this:

    OntologyGenerator generator = new OntologyGenerator();
    generator.AddOntologyHeader("Testing");
    generator.AddClassDeclaration(owlBuilder);
    generator.AddSubClass(owlBuilder);
    generator.AddAnnotationAssertions(owlBuilder);

where that OwlBuilder param you see being passed has collections of objects like this:

public class OwlLBuilder: IOwlLBuilder
{
       private ICollection<IOwlClass> owlClasses = new Collection<IOwlClass>();
       private ICollection<IOwlRelation>  owlRelations = new Collection<IOwlRelation> ();
}

so for example when I say generator.AddClassDeclaration(owlBuilder); it will be looping through owlClasses collection of that owlBuilder param and do some stuff to it…

I feel it is an ugly design. Do you think I can take benefit of modifying my existing code to use Template Method Design Pattern or any other better design suggestions that you have? well with some code sample so I can have the big picture of what I should do in my head!

Answer 1

I really can’t see Template Method in here. I see the Visitor pattern.

Here’s an example.

Imagine you’ve got a bunch of houses, and you need them all to be painted yellow. Now you could just:

var houses = ... a list of houses ...

foreach (var house in houses)
{
    house.Color = Color.Yellow;
}

But instead of always painting your houses yellow, you may want the action (in this case painting) abstracted away into something else. One solution is to write a class that’s responsible for painting a house yellow. That class could later be substituted for another class that paints the house in a different color, or does something completely different with your house, like adding another floor!

Enter the Visitor pattern.

I’ll show some of the generic helper classes and interfaces I’ve been using. I like generics. If you don’t, feel free to roll your own. The semantics are: “a visitor visits a visitable”, and “a visitable accepts a visitor”.

public interface IVisitor<in T> where T : IVisitable<T>
{
    void Visit(T visitable);
}

public interface IVisitable<out T> where T : IVisitable<T>
{
    void Accept(IVisitor<T> visitor);
}

public abstract class Visitable<T> : IVisitable<T> where T : Visitable<T>
{
    public void Accept(IVisitor<T> visitor)
    {
        visitor.Visit((T)this);
    }
}

public abstract class VisitableList<T> : List<T>, IVisitable<T> where T : Visitable<T>
{
    public void Accept(IVisitor<T> visitor)
    {
        foreach (var item in this)
        {
            item.Accept(visitor);
        }
    }
}

Now we can set up our house and our list of houses like this:

public class House : Visitable<House>
{
    public Color Color { get; set; }
}

public class Houses : VisitableList<House> {}

And now, the visitor – our painter – who can visit our visitable house:

public class YellowPainter : IVisitor<House>
{
    public void Visit(House visitable)
    {
        visitable.Color = Color.Yellow;
    }
}

Simple, elegant and a single responsibility(!).

Let’s set up the houses:

var houses = new Houses();
houses.Add(new House() { Color = Color.Green });
houses.Add(new House() { Color = Color.Blue });
houses.Add(new House() { Color = Color.White });

Now we’re ready to paint all of our houses. It only takes one call:

houses.Accept(new YellowPainter());

…and all our houses are now yellow. Nice!

We could just as easily do this:

houses.Accept(new AdditionalFloorsBuilder(floors: 2));

Or this:

owlClasses.Accept(new OwlClassVisitor(owlBuilder, ...));

By doing this, we’ve isolated what happens on the actual “visit” of each element in owlClasses, from the iteration of the collection itself. The visit needn’t modify the visitable. It could be used to only inspect the visitable and use the information to modify something completely different, eg. you could use the information to feed your owlBuilder.