工厂方法（先了解概念）

工厂方法（Factory Method）模式又称为虚拟构造器（Virtual Constructor）模式或者多态工厂（Polymorphic Factory）模式，属于类的创建型模式。在工厂方法模式中，父类负责定义创建对象的公共接口，而子类则负责生成具体的对象，这样做的目的是将类的实例化操作延迟到子类中完成，即由子类来决定究竟应该实体化哪一个类。
在简单工厂模式中，一个工厂类处于对产品类进行实例化的中心位置上，它知道每一个产品类的细节，并决定何时哪一个产品类应当被实例化。简单工厂模式的优点是能够使客户端独立于产品的创建过程，并且在系统中引入新产品时无需对客户端进行修改，缺点是当有新产品要加入到系统中时，必须对工厂类进行修改，以加入必要的处理逻辑。简单工厂模式的致命弱点就是处于核心地位的工厂类，因为一旦它无法确定要对哪个类进行实例化时，就无法使用该模式，而工厂方法模式则可以很好地避免这一问题。
考虑这样一个应用程序框架（Framework），它可以用来浏览各种格式的文档，如TXT、DOC、PDF、HTML等，设计时为了让软件的体系结构能够尽可能地通用，定义了Application和Document这两个抽象父类，客户必须通过它们的子类来处理某一具体类型的文档。例如，要想利用该框架来编写一个PDF文件浏览器，必须先定义PDFApplication和PDFDocument这两个类，它们应该分别继承于Application和Document。
Application的职责是对Document进行管理，并且在需要时创建它们，比如当用户从菜单中选择Open或者New的时候，Application就要负责创建一个Document的实例。显而易见，被实例化的特定Document子类是与具体应用相关的，因此Application无法预测哪个Document的子类将被实例化，它只知道一个新的Document何时（When）被创建，但并不知道哪种（Which）具体的Document将被创建。此时若仍坚持使用简单工厂模式会出现一个非常尴尬的局面：框架必须实例化类，但它只知道不能被实例化的抽象类。
解决的办法是使用工厂方法模式，它封装了哪一个Document子类将被创建的信息，并且能够将这些信息从框架中分离出来。如图1所示，Application的子类重新定义了Application的抽象方法createDocument()，并返回某个恰当的Document子类的实例。我们称createDocument()是一个工厂方法（factory method），因为它非常形象地描述了类的实例化过程，即负责"生产"一个对象。

工厂函数(factory function)
Python2.2统一了类型和类，所有的内建函数现在都也是类，在这基础上，原来的所谓的内建转换函数像int()、type()、list()等，现在都成了工厂函数。虽然看上去像函数，但实质上它们是类，当你在调用它们时，实际上生成了该类的一个实例，就像工厂生产货物一样。

int()、long()、float()、complex()、str()、unicode()、basestring()、list()、tuple()、type()
dict()、bool()、set()、frozenset()、object()、classmethod()、staticmethod()、super()、property()、file()