Constructor or Factory

I had an aha moment the other day. It's nothing that lots of people haven't already figured out, but it helped me see things more clearly, so I'm posting it here.

We were doing some design on some classes for the MSDN project I'm working on, and we were debating how to model a piece of content moving through the system. In the system we're working on, a content set (our term for a page and any other associated files or metadata) flows from the content creator, through a publishing pipeline, and into a database. From there, it's rendered out to the MSDN website.

The problem is that, when content is coming into the system, it starts life as a lump of XML. But when the content is being rendered, it starts life as a database record. Further, there are some properties of the content set that are only present at render time, and some that are only present when the content is being loaded into the the database. We were torn whether to have something like this:

public class ContentSetBase { }
public class DbContentSet : ContentSetBase {
  public DbContentSet() { }
}
public class XmlContentSet : ContentSetBase {
  public XmlContentSet() { }
}
public class ContentSetFactory {
  public DbContentSet CreateContentSetFromDatabase(db args) {}
  public XmlContentSet CreateContentSetFromXml(xml args) {}
}

or something like this:

public class ContentSetBase { }
public class DbContentSet : ContentSetBase {
  public DbContentSet(db args) { }
}
public class XmlContentSet : ContentSetBase {
  public XmlContentSet(xml args) { }
}

The debate was interesting. I was all for the second approach, since I didn't like mixing XML and Database goo in the same class - it just feels like bad separation of concerns. But there was that word...Factory...and it seemed like that's what it was, so it sort of made sense.

I'll admit, I'm not even remotely knowledgable about patterns, but the one I do have sort of a clue about is the factory pattern. You see it all over the place, and it's hugely useful. But here's the trick: it doesn't apply here. Why not? Because the calling code already knows what type of object it wants. Our database loading code always creates an XmlContentSet, and our web page code always creates a DbContentSet. The factory would only be really useful if we were doing something like this:

ContentSetBase cs = ContentSetFactory.Create(args);

and we didn't care whether we got back a DbContentSet or an XmlContentSet. In other words, an important part of the factory pattern is that the factory makes the decision about what type of object to create. In the factory above, the caller was making the decision by calling one or the other method.

Now, that's not to say that the code wouldn't have worked either way: it would have. But it makes more sense to me the second way, and realizing that rule is going to help me figure out in the future when a factory is appropriate, and when it isn't. And that's a useful trick to have in my pocket.

Oh, and in case you were wondering, in the end we wound up doing something else entirely, after figuring out a bunch of other constraints. :)