设计模式 工厂模式

Factroy要解决的问题是：希望能够创建一个对象，但创建过程比较复杂，希望对外隐藏这些细节。

好，那什么是“复杂的创建过程呢“？举几个例子：

例子1

对象代码的作者希望隐藏对象真实的的类型，而构造函数一定要真实的类名才能用。比如作者提供了

abstract class Foo { 
 //...
}

而真实的实现类是

public class FooImplV1 extends Foo {
  // ...
}

但他不希望你知道FooImplV1的存在（没准下次就改成V2了），只希望你知道Foo，所以他必须提供某种类似于这样的方式让你用：

Foo foo = FooCreator.create();
// do something with foo ...

例子2

考虑写个代码的todo。 比如你上司让你读取个文件，然后做某个工作。你在主逻辑中的代码肯定先这样写todo，

// 1 创建对象
// 2 让对象做工作

那么把他翻译成代码就是

// 1 创建对象
CFile file = 一句话创建对象; // (这就是工厂类)
// 2 让对象做工作
file.do();

那我为什么不直接new一个file呢？因为这不是你的工作…

例子3

例子7: 避免在构造函数中抛出异常。"构造函数里不要抛出异常"这条原则很多人都知道。不在这里展开讨论。但问题是，业务要求必须在这里抛一个异常怎么办？就像上面的Foo要求从文件读出来数据并创建对象。但如果文件不存在或者磁盘有问题读不出来都会抛异常。因此用FooCreator.fromFile这个工厂来搞定异常这件事。

作者：大宽宽
链接：https://www.zhihu.com/question/42975862/answer/1239305317

简单工厂、工厂模式和抽象工厂的区别

• 简单工厂

简单工厂的问题在于，当你设计一个新产品A的时候，还要改上司写的工厂类的代码，但是你又没有权限，只能让上司自己改。一段时间后，上司认为，你自己造的产品，让我负责初始化？于是就有了工厂模式，你自己的产品自己初始化，所以初始化逻辑就从工厂类移动到了你自己的类中（就是工厂模式）。

工厂模式其实是对制作流程的抽象，在往上去，其实工厂本身也是一种产品，也可以抽象呀！但是抽象是得有共性的

比如在游戏中，让你生产人族的1，2,3级兵种，和兽族的1,2，3，级兵种，你写todo肯定这么写：

人族兵营.create1();
人族兵营.create2();
兽族.create1();
兽族.create2();

在每个族都有123级兵并且以后可能会有其他种族的时候，你就会把具体工厂（人族兵营和兽族兵营）进行抽象为抽象工厂。