Question

We have a class Event (it’s actually named differently, but I’m just making abstraction):

public class Event
{
    public string Name { get; set; }
    public string Description { get; set; }
    public EventType EventType { get; set; }
}

We need to build an instance of a Message class with this object, but depending on the EventType, we use a different builder:

switch (event.EventType)
{
    case EventType.First:
        message = FirstMessageBuilder.Build(event);
        break;
    case EventType.Second:
        message = SecondMessageBuilder.Build(event);
        break;
}

Do you think this is acceptable, or should we take the following approach:

Make an abstract class:

public class Event
{
    public string Name { get; set; }
    public string Description { get; set; }
    public abstract Message BuildMessage();
}

Then derive two classes: class FirstMessage and class SecondMessage and make the domain objects responsible for building the message.

I hope it isn’t too abstract. The bottom line is we need to transform one class to another. A simple mapper won’t do, because there are properties with XML content and such (due to a legacy application making the events). Just accept what we’re trying to do here.

The real question is: can a domain object be responsible for such a transformation, or would you not recommend it? I would avoid the ugly switch statement, but add complexity somewhere else.

Answer 1

Strictly speaking, a domain object shouldn’t be responsible for anything other than representing the domain. “Changing type” is clearly a technical issue and should be done by some kind of service class, to maintain a clear separation of concerns…