Decorator or Chain of responsibility

Question

My application has a scheduled (weekly) task to populate different attributes of an object. This application will be multi tenant which means, for each tenant, the application might have to populate different/subset attributes. To meet this requirement, I want to choose the right design pattern for my scheduled job. Two design patterns are under active consideration.

1. Decorator
2. Chain of responsibility

The main difference that I could find between these patterns is that, in the former the object gets pass through each class in the pipeline whereas in the latter only one class in the pipeline will act on the object.

For Decorator, I would create separate class for each attribute whereas for chain of responsibility, I would create separate class for each tenant. Is my understanding correct?

ps :: If my understanding is correct, I would prefer Decorator.

Answer 1

I agree with the @markspace comment that the Strategy Pattern appears to be a good solution for the problem you have described.

The key to your solution will be the answer to "how does the process identify the tenant". Once that is solved, the tenant will drive the strategy used.

Answer 2

If I understand the problem correctly, of the two, Chain of Responsibility sounds most appropriate.

I imagine an API like this:

public interface IPopulator
{
    void Populate(Foo foo);
}

You could then have an implementation for each tenant, e.g.

public class Tenant1Populator : IPopulator
{
    private readonly IPopulator next;

    public Tenant1Populator(IPopulator next)
    {
        this.next = next;
    }

    public void Populate(Foo foo)
    {
        if (!IsTenant1(foo))
        {
            next.Populate(foo);
            return;
        }

        // Else, populate foo here...
    }
}

Other implementations would follow a similar template.

There's more than one way to skin this cat, though. Another option is to let each 'handler' internally detect whether it wants to do something to the object or not, and then use the Composite pattern to ask all composed objects to do their thing.

FWIW, the drawing in the OP looks appropriate to me. The Decorator pattern would enable you to let each class do part of the job. If this is more desirable, then that could work, too.

It really depends on which part of the code you expect to have to change the most.