factory模式 （建構子）

這其實應該算是「constructor」的衍伸。

因為factory模組要的就是如何產生物件實體。

如以下範例（取自「壞蛋的密室」）：

class Symbol {
  final String name;
  static Map<String, Symbol> _cache;

  factory Symbol(String name) {
    if (_cache == null) {
      _cache = {};
    }

    if (_cache.containsKey(name)) {
      return _cache[name];
    } else {
      final symbol = new Symbol._internal(name);
      _cache[name] = symbol;
      return symbol;
    }
  }

  Symbol._internal(this.name);
}

使用方式如下：

var a = new Symbol('something');
var b = new Symbol('something');
assert(identical(a, b)); // true!

常識來說，constructor自預設「return 實體」做結尾，但Dart/Flutter的factory模組可以加在constructor中。

在constructor前面加上「factory」，同時必須要用「return返回實體」做constructor的結尾。

這樣的做法雖然在使用上很方便（不用再寫Factory模式），但在邏輯上和物件導向使用上，可能會帶來很嚴重的混亂。

最明顯的問題是：Factory模式並不預設return用來實作Factory的物件自己，總是會return一系列擴充了A介面或物件的A1/A2/A3/A4...。

如果物件自己就是Factory模式，那請問要怎麼返回子類別呢？

這問題很奇妙。

因為這問題顯示了物件導向編譯程式並沒有想像中的符合人類的直覺或思考模式。

試想像一下：物件A在編譯的時候，要如何知道自己的子類別存在呢？

但事實是：這樣的程式技巧確實存在。也就是說「編譯器能否編譯這樣的物件」決定了最終的答案，不需要任何理論去解釋，只要知道「可以這樣做」即可。

也就是說「如果Dart/Flutter提供這樣的模式，我們可以預設：它支援這樣的設計。」