Saturday, June 21, 2014

Dart Factory Method Pattern

It's time to start laying the foundation for Design Patterns in Dart. There is still work to be done on Patterns in Polymer (especially the screencasts for “Extras” readers), but for a variety of reasons, I need to start exploring how I am going to approach a design patterns book.

I have vague plans for how I would like to organize the book. Some of those plans will work, others… not so much. One of my best laid plans is to include examples of each pattern from the wild—similar to the original classic. I am unsure how well that will work. It is difficult, at best, to find implementations of each pattern in the wild that are clean enough to lend support to a book narrative. Since Dart is so new, it will be that much more difficult to find such examples (though I have definitely seen more than a few).

Regardless, I might as well start somewhere, so tonight… I cheat.

I start with the Factory Method pattern. What makes this a cheat is the source of it in the “wild.” I first saw this in Dart when I used it while building the Hipster MVC framework to support part of the narrative in Dart for Hipsters.

I actually went out of my way to not refer to this as a pattern at the time, but I need to start referring to things with proper names—especially if I am going to write a book in which names are so important. So…

Hipster MVC provides an abstract creator class in the form of HispterCollection:
abstract class HipsterCollection extends IterableBase {
  HipsterModel modelMaker(attrs);
  String get url;
  // ...
The factory method in this class is modelMaker().

The concrete creator class comes from the dart-comics repository. The Comics class extends the HipsterCollection abstract creator class and implements the creator method:
class Comics extends HipsterCollection {
  modelMaker(attrs) => new ComicBook(attrs);
  get url => '/comics';
Dang, that's actually a pretty nice example. Event the return type from the abstract and concrete creator classes line up. The abstract class declares it as HipsterModel and the concrete class returns a new ComicBook instance, which is a subclass of HipsterModel:
class ComicBook extends HipsterModel {
  ComicBook(attributes) : super(attributes);
About the only thing missing is the ability to create instances of ComicBook from a class name instead of method. This is given as an example in the Gang of Four book (in Smalltalk). It is also something that I, coming from a Perl, Ruby, JavaScript, anything-but-Java background would have preferred to use when I first wrote Dart for Hipsters. But it was not an option at the time since Dart lacked support for mirrors.

Now that Dart has some pretty nice support for mirrors, this ought to work just fine. And so I will tackle that tomorrow.

Day #100


  1. Not forgetting the factory constructor built in to the Dart language. Though I assume you will be getting to that later :-)

    1. Yup. One of my other bright ideas for the book is to include discussion for how Dart makes some of the patterns easy/trivial (Iterator — I'm looking at you!).

      That said, and despite the similarity in names, I don't think factory constructors are useful with Factory Method. Well, maybe a little with mirrors -- we'll see :)

    2. Well if you want to implement it exactly how The Gang of 4 did, then yes, it's not the same. Then they were doing it with C++ and Smalltalk, and I think the Dart factory constructor would fit their intention for the pattern. Also I don't think Mirrors are necessary at all for the factory method, but it is one way to do it.

    3. I realised, by the way, after we spoke one time about this book and you showed me the book by the Gang of 4, and I didn't think I'd read it. I had, and I bought it twice, by accident the second time. Once from Amazon, then again from Google Books. It's a hard read, and I didn't click to what it was, till ages later after I'd read it. I thought this was more patterns based upon further research by some people who happened to have worked at IBM at one time or another. Just shows you don't know what you got, but in my case it hasn't gone, or been lost :-)

    4. Mirrors definitely are not necessary. I'm just too much of a dynamic language wonk to _not_ try them :)

      The GoF book was a tough read for me as well. Going through it for this book will easily be the closest that I look and attempt to internalize what they were saying. Which is entirely the point of course!

      I'll also be looking at other patterns beyond the GoF. My initial starting point will be: though I will try to identify a Dart specific pattern or two as well. I'm excited about the project :)