Named Constructors in Dart Factory Method

As pointed out to me in comments, Dart mirrors are unlikely to be the most efficient means for implementing the Factory Method pattern in Dart. But I don't care, I love this dynamic language stuff too darn much.

OK, OK, that's not 100% true. I do care about speed and efficiency in my code. I also very much care about speed a a factor for the solutions that will go into Design Patterns in Dart. That said, I am not trying to find the one and only solution when I first investigate a pattern. I am interested in finding as many reasonable implementations as possible so that I might have several to fit different use cases in the book.

Sometimes speed might be the most important need, sometimes it might be clarity, and other times a programmer may need a solution that minimizes the number of classes and subclasses. I really also ought to include potential drawbacks to each pattern or, as the Gang of Four book puts it, consequences of each. One of the consequences of the Factory Method pattern mentioned by the Gang of Four is the difficulty that arises when refactoring constructors.

Since the Factory Method pattern concerns itself with creating new objects, the difficulty in refactoring arises when the constructor needs to change. Consider the concrete creator in the Hipster MVC framework:

class Comics extends HipsterCollection {
  modelMaker(attrs) => new ComicBook(attrs);
  get url => '/comics';
}

In this case, the modelMaker() method plays the role of Factory Method. Where the HipsterCollection base class leaves this method abstract, the concrete creator must define the implementation. But what happens when the constructor has to change because some unrelated client code needs to supply different arguments? What happens when Hipster MVC becomes super popular only to find that a single argument to modelMaker() is insufficient in 20% of the use cases? Is a huge rewrite inevitable? Is a breaking, major version change the only option?

Thanks to Dart's optional method parameters, I could probably accommodate some change, but it would be nice if these kinds of changes could occur independently of each other. This seems like a job for Dart's named constructors.

Currently, my Factory Pattern's abstract product class, HispterModel, declares a constructor that optionally accepts attributes:

class HipsterModel {
  // ...
  HipsterModel([this.attributes]) {
    if (attributes == null) attributes = {};
    _onSave = new StreamController.broadcast();
    _onDelete = new StreamController.broadcast();
  }
  // ...
}

It might make sense for this default constructor to treat attributes as optional, but when creating concrete products as part of a collection, this might prove problematic. With named constructors, I can leave the default case as optionally accepting mode attributes, but, when constructed from a collection, it can be required:

class HipsterModel {
  // ...
  HipsterModel([this.attributes]) {
    if (attributes == null) attributes = {};
    _onSave = new StreamController.broadcast();
    _onDelete = new StreamController.broadcast();
  }
  HipsterModel.collectionMaker(Map attrs): this(attrs);
  // ...
}

My concrete creator would use this named constructor in the Factory Method:

class Comics extends HipsterCollection {
  modelMaker(attrs) => new ComicBook.collectionMaker(attrs);
  get url => '/comics';
}

This has the advantage of allowing the two constructors to evolve independently of each other, which is a decided win. This would also play nicely with last night's mirror-based Factory Method implementation.

But all is not rosy with this approach—mostly due to Dart's treatment of constructors in subclasses. Specifically, they are not inherited. Because of this, I already had to declare a constructor for the optional arguments version. Now I have to do so for the named constructor as well:

class ComicBook extends HipsterModel {
  ComicBook([attributes]) : super(attributes);
  ComicBook.collectionMaker(attributes) : super.collectionMaker(attributes);
}

There is no way around this restriction in Dart. If concrete product classes like ComicBook are needed (because they define some additional, domain-specific properties or methods), then I will need to declare both constructors.

There might be cases in which this overhead is acceptable—maybe even desirable. Even so, it is probably worth some more investigation in this area to see if more general purpose solutions exist. Toward that end, I will pick back up with factory constructors tomorrow.


Day #102

‹prev | My Chain | next›