Python 设计模式之工厂函数模式

工厂函数模式是一种创建型设计模式，抛出问题：

1. 什么是工厂函数模式？
2. 为什么会用到工厂函数模式？
3. 工厂函数模式和抽象工厂模式有什么关系？

案例

基本案例

为了理解这些问题，需要引入一个场景案例：

一个城市的公共交通一开始只有公交车,该城市通过调用公交车解决城市人流的流动:

def transfer(people):
    print(f"move {people} mans to other place")

def main():
    people = 100
    transfer(people)

随着城市的发展，开始支持地铁，并且这些交通方式也有了复杂的定义，于是新的版本：

class Bus:
    def transfer(self, people):
        print(f"move {people} mans to other place on Road")

class Subway:
    def transfer(self, people):
        print(f"move {people} mans to other place under ground")

def main():
    people = 100
    w = Bus()
    w.transfer(people)

main()

这里我们利用打印语句内容的不同来暗示它们的行为不同，而 main 函数作为客户端代码只需要通过调用不同的交通方式类来得到实例对象，再调用具体方法即可达成目的。假如还有其他交通方式引入，那就再实现多一个类就可以了。这个版本到这里并没有什么不好。
这个城市后来又发展出轮渡的交通方式，同时客户端代码的逻辑也变得更加复杂，对交通方式的实例类的调用也更频繁，原来只是调用 w.transfer(people),现在还需要执行载货、或者设备报告等等方式，这意味着每次引入一个新的交通方式类，就要保证这个新的类的引入不会导致客户端的代码不会出错。

1. 新的类没有实现的方法，而客户端代码中在后面调用了
2. 有些行为只有某一个产品才有
3. 新的维护者用其他方式命名了该方法

为了规避这些问题，开发者对这些交通方式（产品）进行了抽象（抽象产品），任何新引入的交通方式必须继承这个抽象产品，并且实现这个抽象产品中的基本方法，于是这个类关系图变成:

而据此实现的新版本：

from abc import ABC, abstractmethod

class Product(ABC):
    @abstractmethod
    def transfer(self, people):
        ...

class Bus(Product):
    def transfer(self, people):
        print(f"move {people} mans to other place on Road")

class Subway(Product):
    def transfer(self, people):
        print(f"move {people} mans to other place under ground")

class Ship(Product):
    def transfer(self, people):
        print(f"move {people} mans to other place on sea")

def main():
    people = 100
    w = Ship()
    w.transfer(people)

main()

在这种方式下，如果继承自 Product 的交通方式不实现其定义的抽象接口就无法实例化。进行到这里实际上关于工厂函数的四个角色，我们已经引出了两个，即下面标红的抽象产品和具体产品，指代我们的交通方式和具体交通方式

1. Creator
2. Concrete Creator
3. Product
4. Concrete Product

逐渐复杂的案例

让我们继续给这个上面的案例加多一些现实场景：

随着发展，每一种具体的交通方式都有了各自复杂多样的类型（具备不同属性的实例）。以前只有一辆24座的红色巴士，现在城市发展了，有50座红色巴士、50座绿色巴士、使用新能源的、使用汽油的…这样的情况在地铁和轮船上也是如此。
而针对运输一批市民的需求，也要根据实际情况不同选择合适的产品，就算是用巴士运载，也要选用合适座位数等属性的大巴车进行调度。

这体现在我们的代码中是怎样的呢？以 Bus 为例：

class Bus(Product):
    def __init__(self, seat, color, energy):
        self.color = color
        self.seat = seat
        self.energy = energy
        
    def transfer(self, people):
        print(f"move {people} mans to other place on Road")

def main():
    people = 100
    if people < 24:
        w = Bus(color="red", seat=24, energy="电")
    else:
        w = Bus(color="red", seat=120, energy="油")
    w.transfer(people)

main()

可以看到，客户端代码需要根据情景不同生成不同属性的实例，这还只是考虑了一个属性（人数）的逻辑，如果还需根据其他基本信息，那客户端代码就更复杂了，比如：

1. 目的地不同选择电还是油？
2. 同样是人数小于 24人时，生成轮船所需的配置参数和大巴的配置参数不同

这些问题如果都交给客户端去解决的话，那就会导致：

1. 一旦引入新的产品就要修改一次代码
2. 客户端需要负责实例的生成，高度的耦合

那么可不可以客户端只负责提出：

1. 期望的产品（实例类型：大巴还是轮船）
2. 问题的基本信息（人数、目的地…）即生成实例的基本参数

这样的背景下，我们引入创建者角色，由创建者根据不同的入参创建不同属性配置的实例

而轮船也有其对应的轮船创建者、地铁对应其地铁创建者，这类创建者多了之后就衍生了规范，每一种创建者需要遵循某种基本规范:

讲到这里，我们就引入了抽象创建者和具体创建者, 到此工厂函数模式的四个角色就都到齐了。让我们把这新出现的两个角色也整合进代码中：

from abc import ABC, abstractmethod

class Product(ABC):
    @abstractmethod
    def transfer(self, people):
        ...

class Bus(Product):
    def __init__(self, seat, color, energy):
        self.color = color
        self.seat = seat
        self.energy = energy
    
    def transfer(self, people):
        print(f"move {people} mans to other place on Road")

class Subway(Product):
    def transfer(self, people):
        print(f"move {people} mans to other place under ground")

class Ship(Product):
    def transfer(self, people):
        print(f"move {people} mans to other place on sea")

class Creator(ABC):
    @abstractmethod
    def create_transportation(self):
        ...

class BusCreator(Creator):
    def __init__(self, people):
        self.expected_people = people
    
    def create_transportation(self):
        if self.expected_people < 24:
            return Bus(seat=24,color="red", energy="油")
        return Bus(seat=120,color="yellow", energy="电")

class ShipCreator(Creator):
    def create_transportation(self):
        return Ship()

def main():
    people = 10
    creator = BusCreator(people)
    w = creator.create_transportation()
    w.transfer(people)
    print(w.seat)

main()

可以看到复杂的实例生成逻辑已经被我们从 main 函数即客户端代码中抽离出来，而如果使用者希望轮船这个产品，他只需更换为对应的创建者即可，即使轮船实例有其特殊的创建逻辑也无需考虑。
现在我们这段代码的类关系图如下：

客户端代码不直接调用具体产品类（Bus）来得到具体实例 Bus instance，而是通过调用具体创建者（BusCreator）来获得具体实例。

问题回顾

现在回过头来看博客开头提到的三个问题

什么是工厂模式？

模式定义

在工厂方法模式中，工厂父类负责定义创建产品对象的公共接口，而工厂子类则负责生成具体的产品对象，这样做的目的是将产品类的实例化操作延迟到工厂子类中完成，即通过工厂子类来确定究竟应该实例化哪一个具体产品类。

这里的工厂父类是指抽象创建者Creator, 它提供了一个需要被实现的抽象方法 creat_transportation, 而让其子类在这个函数里实现实例化对象时的定制逻辑

工厂方法模式建议使用特殊的工厂方法代替对于对象构造函数的直接调用。而上面的案例用具体创建者的函数 creat_transportation (工厂方法) 代替直接使用 Bus() (即客户端直接使用 Bus.__init__() )

模式结构

工厂方法模式包含如下角色：

• Product：抽象产品
• ConcreteProduct：具体产品
• Factory：抽象工厂
• ConcreteFactory：具体工厂

这四种角色，上面在案例中已经做了拆解就不做赘述。

为什么会用到工厂函数模式？

在上面的案例演变中，我觉得你应该得到这个问题的答案。如果没有，那么概括下：

1. 如果这是一个简单的对象，不涉及复杂的实例创建过程，那么不需要应用这个模式，反过来讲，使用工厂函数模式是为了解决在客户端代码需要根据具体场景创建具体的复杂实例的问题。

工厂函数模式和抽象工厂模式有什么关系？

到点吃饭了，这个问题暂时先不展开论述了，其实你仔细看上面的代码可以发现有部分抽象工厂模式的思想。

• 虽然代码示例中没有直接展示出抽象工厂模式的完整结构，但可以看到 Product 是一个抽象类，定义了产品的抽象接口 transfer()，而具体的产品类 Bus、Subway 和 Ship 实现了这个接口。
• Creator 类可以被视为一个抽象工厂，定义了一个创建产品的抽象方法 create_transportation()，而 BusCreator 和 ShipCreator 则是具体工厂，实现了 Creator 接口并负责创建具体产品。

关系和区别

• 关系：工厂函数模式可以被看作是抽象工厂模式的一种简化形式，特别是在只需创建单一种类的情况下。它们都用于将对象的创建与使用代码分离，提高系统的可扩展性和灵活性。
• 区别：主要区别在于抽象工厂模式更加抽象和灵活，能够创建一组相关对象（产品家族），而工厂函数模式通常只涉及单一对象类型的创建。抽象工厂模式还涉及多个抽象类或接口的定义和实现，更适用于需要创建多个相关对象的场景。