一、在没有使用设计模式之前，我相信很多Coder都是这样创建对象的：
在项目中这样直接使用类去New一个对象，它会有哪些缺点呢？作为上端（调用方）过于依赖下端（细节部分），是紧密耦合在一起的，如果我们的细节部门发生了改变，那么我们的上端代码也是需要做改变的，怎么解决这个问题，那么我们可以使用一种抽象思维：把对象的创建放到一个工厂里去做，这个工厂只负责对象的创建，然后返回一个接口类型：
二、简单工厂
这样基本实现了一个简单工厂：在调用方（上端代码）基本不会去依赖具体的细节部门，但还是存在一个问题，上端代码在使用工厂类创建对象的时候还需要传递参数，所以接下来做了一个简单方法的升级版本（使用简单工厂 + 配置文件）
简单工厂的好处是显而易见的，实现了解耦，但是我们会发现另一个问题，简单工厂只是把矛盾转移了，并且把矛盾还集中了，工厂类的CreateInstance方法责任太重大，所有手机类的改动，都可能会影响这个类方法的改动，严重违背了单一职责，因为它有创建多种手机的职责，针对这个问题，我们的工厂方法就出来了
三、工厂方法
其实工厂方法就是将工厂类的创建实例方法，拆分成多个方法，这样每个方法职责肯定是单一的。
写到这里，每个手机的创建都有单独的工厂去创建，每个工厂类负责一个对象的创建，把简单工厂的创建实例的方法进行了拆分，也实现了具体业务类的延迟创建。但总感觉代码量有点大，如果实际业务比较多，每个类的创建都需要创建工厂的话，其实也是有点累赘的。但工厂方法它是对扩展开放的，对修改封闭的，如果市场上又出现了一款手机，我需要创建实例的时候，只需要添加新的手机类和工厂类即可，只是增加了代码，而简单工厂还需要对工厂类的方法进行修改，违背了设计模式的六大原则之一：开闭原则。这个原则在程序设计中是一个很重要的原则，我们宁愿多写代码去扩展功能，也不愿对原来的代码进行大量的修改。所以这也是工厂方法带给我们的好处。
设计模式本来就是开发人员在程序开发过程中的经验总结，也没有一定之规，所以它本身是有长处和短处的，我们的目标就是取长补短。
另外，对象的延迟创建是有很多好处的，我们在工厂类里创建对象之前还可以写很多逻辑，实现我们更多的业务
四、抽象工厂
抽象工厂其实就是对产品的扩展，对工厂再进行一下抽象，比方说：现在有一个造手机的工厂和造电脑的工厂，它们属于不同的产品，所以我们可以对这两个工厂做一个抽象。
到此为止：可以看出抽象工厂是对产品的一个扩展，具体细节的创建，还是在某一个单独的工厂里面