工厂方法模式：定义一个用于创建对象的接口，让子类决定实例化哪个类。
工厂方法把简单工厂的内部判断逻辑移到了客户端代码，本来需要修改工厂类，现在是修改客户端。
简单工厂模式违背了开放-封闭原则，工厂方法模式借助多态，克服了该缺点，却保持了封装对象创建过程的优点。
子类决定实例化。让客户端代码进行实例创建。
如果有新的对象增加,只需要增加一个具体的类和具体的工厂类即可
抽象工厂模式：提供一个创建一系列相关或互相依赖对象的接口，只需要知道对象的系列，无需知道具体的对象。
在客户端中，具体工厂类只在初始化时出现一次，更改产品系列即可使用不同产品配置。
利用简单工厂类替换抽象工厂类及其子类，可以使客户端不再受不同系列的影响。
结合反射机制，Assembly.Load(“程序集名称”).CreateInstance(“命名空间”.“类名”)，可以直接通过字符串创建对应类的实例。所有在简单工厂中，都可以通过反射去除switch或if，解除分支判断带来的耦合。
反射中使用的字符串可以通过配置文件传入，避免更改代码。
抽象工厂模式（Abstract Factory Pattern）是围绕一个超级工厂创建其他工厂。该超级工厂又称为其他工厂的工厂。这种类型的设计模式属于创建型模式，它提供了一种创建对象的最佳方式。
在抽象工厂模式中，接口是负责创建一个相关对象的工厂，不需要显式指定它们的类。每个生成的工厂都能按照工厂模式提供对象。
用 OOP 的思想去理解，所有的衣柜（具体工厂）都是衣柜类的（抽象工厂）某一个，而每一件成套的衣服又包括具体的上衣（某一具体产品），裤子（某一具体产品），这些具体的上衣其实也都是上衣（抽象产品），具体的裤子也都是裤子（另一个抽象产品）。
- 工厂模式: 接受factory作为输入。
如果你意识到你不能够追踪应用的对象创建，那是因为这些代码被写在很多地方而不是一个单独的函数或者方法，你就应该考虑使用那个工厂方法模式。工厂方法使一个对象的创建集中化，追踪对象也变得非常简单。
工厂方法在你想要从对象使用中分离对象创建时也是大有裨益的。我们在创建一个对象时不合并或者绑定到一个指定的类，通过调用一个函数我们只提供我们所想要的部分信息。这意味着将改变引入到函数很简单而且不要求任何对所使用代码的改变。
因为抽象工模式是工厂方法模式的归纳，它具有同样的优点：使得追踪一个对象创建更容易，它让对象的使用和创建分离开，并且给我们内存使用以及应用的性能提高的可能。
但是问题来了：我们如何知道什么时候使用工厂模式还是抽象工厂？答案是我们通常以更简单的工厂模式开始。如果我们发现应用需要很多的工厂模式,要让它变得有意义就要合并同族对象，那么我们就使用它。抽象工厂的好处站在用户的角度来看不是很明显，但是在使用工厂模式时，通过改变活动的工厂方法它给了我们修改动态的应用（运行中的）的能力。
django里面的数据库类、redis类等概念。通过配置文件进行需要类的实现与切换
- 简单工厂： 将实例抽象，把创建实例的操作细节都放到了工厂里面去实现。客户端进行传参创建。工厂会有大量的switch判断
- 工厂模式：在简单工厂模式里集中在工厂方法上的压力，可以由工厂方法模式里不同的工厂子类来分担。也就是通过继承达到创建不用的工厂，然后通过统一的create接口，创建不同的实例。
工厂方法模式的对简单工厂模式进行了抽象。有一个抽象的Factory类（可以是抽象类和接口），这个类将不在负责具体的产品生产，而是只制定一些规范，具体的生产工作由其子类去完成。
高层模块不直接依赖低层的实现，而是依赖于低层模块的抽象
通过继承，实现各种类的创建。统一的create接口创建实例, 然后把工厂创建的类传进去client里面，注意也不是在client里面直接实例化。工厂类的目的就是统一创建入口，需要更改的时候能灵活切换。而无须改逻辑代码。依赖注入可以说是工厂模式。
- 抽象工厂：工厂方法模式只有一个抽象产品类，而抽象工厂模式有多个。 也就是一个抽象工厂，创建一个具体的工厂，工厂创建不同的产品。或者创建另一个具体的工厂，创建跟上一个工厂不一样的产品。
抽象工厂，如果工厂有一系列重复的创建，则可以作为工厂的抽象。
RequestFactory与测试客户机共享相同的API。但是，RequestFactory提供了一种生成请求实例的方法，该实例可以用作任何视图的第一个参数，而不是像浏览器那样工作。这意味着您可以像测试任何其他函数一样测试视图函数—作为一个黑盒，使用完全已知的输入，测试特定的输出。
通过RequestFactory创建view_fun(request)的request类。可以理解为工厂模式通过传参把factory传入。
您可以使用独立函数modelform_factory（）而不是使用类定义从给定模型创建表单。如果您无需进行许多自定义，这可能会更方便。