Question

I was implementing a decorator the other day and later that night I started wondering if something like the example below was a valid representation of the decorator pattern.

public abstract class Foo
{
    public List<string> Names { get; set; }

    public abstract string GetNames();
}

public abstract class BarDecorator : Foo
{
    public abstract String GetNames();
}

public class JustAnOldBar : Foo
{
    public JustAnOldBar() {
        this.Names.Add("An Old Bar");
    }

    public override string GetNames()
    {
        return string.Join(",", this.Names.ToArray());
    }
}

public class SomeDecorator : BarDecorator {
    private Foo foo;

    public SomeDecorator(Foo someFoo) {
        this.foo = someFoo;
    }

    public override string GetNames()
    {
        return string.Join(",", this.Names) + "," + string.Join(",", this.foo.Names);
    }
}

Usually, when I implement this pattern, I’m looking at a single member that I’m pulling across like cost or description, but I wonder if it’s appropriate to operate on a collection with a decorator or if you should start looking at a builder when it comes to this point.

Answer 1

Decorating, in the Decorator pattern, has no dependency of the fields (if any) that are involved in the decoration. It is about modifying the behavior of decorated classes. As exampled in the wiki definition, it might just as well decorate the drawing behavior of a window, rather than manipulate a field or return value of a method.

In short – as Wiktor Zychla commented – no problem with that.