正文
工厂模式也是23种设计模式中比较常用的模式之一，而这23种设计模式的又可以分为：创建型模式、结构性模式和行为型模式，工厂模式归类为创建型模式。
一般情况下工厂模式又可以细分简单工厂模式、工厂方法模式以及抽象工厂模式3种，简单工厂模式严格来说并不是工厂模式的一种，而是一种编程习惯。在本文中为了对比理解所以将也简单工厂作为了一种模式
简单工厂模式
简单工厂（Simple Factory）模式是由一个工厂类根据传入的参数，动态决定应该创建哪一个产品类（这些产品类继承自一个父类或接口）的实例。一般简单工厂模式又称为静态工厂方法(Static Factory Method)模式，它属于类创建型模式。
![simple_factory]()
接下来我们通过一个简单的例子演示一下简单工厂模式。首先定义一个用于绘制图形的接口Shape，该接口中定义了一个可以绘制的方法draw()。圆形Circle、正方形Square以及矩形Rectangle都会实现Shape类，然后实现自己的draw()方法。
我们将对Shape各种不同的实现通过一个工厂类ShapeFactory返回。
除了通过传入一个type类型之外，还有另外一种方式就是直接传入需要创建类型的一个Class，然后通过反射的方式直接返回一个Shape对象类型。
上面两种不同创建对象的方法是类似的，都要通过一个入参创建不同类型的对象。
优点
工厂类是整个模式的关键。包含了必要的逻辑判断，根据外界给定的信息，决定究竟应该创建哪个具体类的对象。通过使用工厂类，外界可以从直接创建具体产品对象的尴尬局面摆脱出来，仅仅需要负责“消费”对象就可以了。而不必管这些对象究竟如何创建及如何组织的。明确了各自的职责和权利，有利于整个软件体系结构的优化。
缺点
由于工厂类集中了所有实例的创建逻辑，违反了高内聚责任分配原则，将全部创建逻辑集中到了一个工厂类中；它所能创建的类只能是事先考虑到的，如果需要添加新的类，则就需要改变工厂类了。当系统中的具体产品类不断增多时候，可能会出现要求工厂类根据不同条件创建不同实例的需求。这种对条件的判断和对具体产品类型的判断交错在一起，很难避免模块功能的蔓延，对系统的维护和扩展非常不利。
使用场景
-
工厂类负责创建的对象比较少；
-
客户只知道传入工厂类的参数，对于如何创建对象（逻辑）不关心；
工厂方法模式
通过定义一个创建对象的接口，让子类确定实例化哪一个类。工厂方法使一个类的实例化延迟到了子类。
工厂方法类图如下：
![factory_method]()
我们知道无论是在Android还是Java的Swing框架中，视图的主题都是可以自己设置的，ScrollBar在深色主题和浅色主题中外观颜色是不一样的。假设主题的实体类就是一个Theme类，然后定义一个用于创建主题的接口ThemeFactory，接口中有一个方法createTheme()方法，返回的是Theme实例。ScrollBar跟上面的简单工厂定义的类似，实现Shape接口重写draw方法。
根据上面类图的表示，在该示例中将Theme的抽象这一层简化了，而是直接使用的ConcreteProduct就是Theme。
通过实现ThemeFactory我们定义两个主题，一个是LightThemeFactory浅色主题，一个是DarkThemeFactory深色主题。
