工厂设计模式（因为太过概念化而没有java实现）

工厂设计模式思想

  和绝大多数设计模式一样，工厂设计模式是为了实现开闭原则。这话是不是哪里听过？没错，我在单例设计模式中说了同样的话。实际上单例设计模式可以被看作工厂设计模式的一种。（但也不完全是)
  从抽象的角度来看，一个对象实际上是一堆属性的集合。从一个对象生成，到这个对象可用之前，我们需要小心仔细的给对象的每一个属性赋上正确的值。
  面向对象思想教育我们对象的属性初始化应该交给构造函数来完成。在大多数简单的情况下确实是这样的，然而我们总是会遇见非常复杂的对象初始化过程，尤其是有如下的要求的时候：

1. 该对象的某些字段依赖初始值于某些不应该由本对象持有的字段。
2. 该对象的某些字段依赖于运行时才能确定的值。
3. 该对象的某些值需要通过同步保持一致性（并发创建对象）
4. 等等。。。

  构造函数过于复杂几个坏处：

1. 导致复杂的耦合：构造函数中出现一堆指向别的对象的指针/引用会导致复杂的耦合。后期扩展代码会异常痛苦。
2. 难以扩展/复用：当我们需要扩展构建对象的逻辑的时候，父对象构造函数中的复杂逻辑将会成为噩梦。如果这些代码年久失修，重新理解他们往往比重写一次还难。你不知道构造的什么时候，哪些属性是可用的。除了super你没有复用这些代码的手段。

把构建逻辑从构造函数中抽离出来

  对象不应该管理复杂的如何构建自己的逻辑，而只应该管理自己属性之间的内部关系。这意味着我们应该单独把构建逻辑放到另外一个地方，而这个地方就是工厂。
  工厂模式很好的解决了上面提到的很多问题：

1. 工厂类持有要生成的类之外的其他对象/类的引用是很正常的，实际上正需要它来表达这种联系，这种联系在类图中会非常清晰。
2. 工厂类可以在包括并发在内的复杂逻辑中控制一个对象的构建，在java中，工厂类可以使用包括synchronise关键字/自旋锁在内的各种同步手段，在javascript中，工厂类返回一个Promise也是常见的。
3. 工厂类构建对象的过程中可以使用多个子过程，这些子过程可以使用包括控制反转在内的其他设计模式保持高扩展性。
4. 你再想想上面这些代码全部挤到构造函数里会是怎样的噩梦。

抽象工厂类

  抽象工厂类专门用于表示那种组合了多个类型的类型，不同的组合方式表达了不同种类的类，而使用不同的工厂类可以生成不同种类的该类。
  我个人觉得这种工厂类没有直接使用依赖注入来使用不同的实现来的灵活。