工厂模式+抽象类实战指南（基于文档导出业务）

一、引言

在实际业务开发中，经常会遇到「同类多实现」的需求场景（如文档导出支持Word、PDF、Excel格式，后续可能新增TXT、CSV）。这类需求的核心痛点是：对象创建逻辑复杂、业务层与具体实现耦合高、新增功能需修改多处代码。而「工厂模式+抽象类」的组合，正是解决该类问题的最优方案------通过抽象类定约束，工厂模式统一创建对象，实现代码规范、低耦合、易扩展。

二、不用工厂模式+抽象类：业务代码与开发痛点

1. 业务代码实现（文档导出功能）

python 复制代码

# 具体导出实现类（无统一约束）
class PdfExporter:
    def export(self, content: str):
        print(f"PDF导出：{content}")

class WordExporter:
    def export(self, content: str):
        print(f"Word导出：{content}")

# 业务层直接处理创建与调用
def export_content(content: str, export_type: str):
    # 手动判断类型+直接创建对象
    if export_type == "pdf":
        exporter = PdfExporter()
        exporter.export(content)
    elif export_type == "word":
        exporter = WordExporter()
        exporter.export(content)
    # 新增格式需在此处添加elif判断

# 调用方式
export_content("测试内容", "pdf")

2. 实际开发痛点（必踩坑）

耦合度极高 ：业务层需手动写if-else判断类型，还要直接创建PdfExporter等具体类，需关心对象创建细节（如后续PDF导出需配置密钥，需在业务层修改）。
扩展成本高 ：新增TXT导出时，需在业务层的if-else中新增分支，若多个地方调用导出功能，需修改所有调用处，易漏改、出错。
团队协作易出错 ：无统一接口约束，开发人员可能写错方法名（如将export写成export_txt），仅在运行时才报错，排查成本高。

三、用工厂模式+抽象类：重构方案与代码实现

1. 核心设计思路

抽象类：定义统一接口（如export方法），强制所有实现类遵守规范，提前暴露错误。
工厂类：统一管理对象创建逻辑，屏蔽创建细节（如初始化配置），业务层仅需传递类型参数。
业务层：无需关心对象创建，仅调用抽象类定义的方法，实现"依赖抽象不依赖具体"。

2. 完整代码实现

python 复制代码

from abc import ABCMeta, abstractmethod

# 1. 抽象类：定义统一约束（核心：定规矩，强制子类实现export方法）
class BaseExporter(metaclass=ABCMeta):
    @abstractmethod
    def export(self, content: str) -> None:
        pass  # 抽象方法仅定接口，不写具体逻辑

# 2. 具体实现类：遵守抽象类约束，实现具体导出逻辑
class PdfExporter(BaseExporter):
    def export(self, content: str):
        # 可在此添加复杂初始化（如配置PDF编码、分页），业务层无需关心
        print(f"✅ PDF导出成功：{content}")

class WordExporter(BaseExporter):
    def export(self, content: str):
        print(f"✅ Word导出成功：{content}")

class TxtExporter(BaseExporter):
    def export(self, content: str):  # 必须实现export方法，否则编译报错
        print(f"✅ TXT导出成功：{content}")

# 3. 工厂类：统一创建对象，屏蔽创建细节
class ExporterFactory:
    @staticmethod
    def get_exporter(export_type: str) -> BaseExporter:
        if export_type == "pdf":
            return PdfExporter()
        elif export_type == "word":
            return WordExporter()
        elif export_type == "txt":  # 新增格式仅需修改工厂类
            return TxtExporter()
        else:
            raise ValueError(f"不支持的导出格式：{export_type}")

# 4. 业务层：简洁调用，无需关心创建逻辑
def export_content(content: str, export_type: str):
    exporter = ExporterFactory.get_exporter(export_type)
    exporter.export(content)  # 放心调用，抽象类已保证有export方法

# 调用方式（新增格式后，调用逻辑不变）
if __name__ == "__main__":
    export_content("工厂模式实战案例", "pdf")
    export_content("工厂模式实战案例", "txt")  # 新增TXT格式，直接调用

四、核心作用总结

1. 抽象类的核心价值：「强约束+统一接口」

强制规范：所有子类必须实现export方法，避免写错方法名、漏写核心逻辑，编译时暴露错误，无需等到运行时。
统一调用：业务层仅需调用抽象类的export方法，无需关注不同格式的实现差异（如PDF编码、Word格式配置）。
提升可读性：看到BaseExporter即可明确，所有子类均为"文档导出工具"，项目越大越能体现价值。

2. 工厂模式的核心价值：「解耦+易扩展」

解耦创建逻辑：将对象创建（new PdfExporter()）与业务逻辑分离，业务层无需关心对象初始化细节（如密钥配置、依赖注入）。
简化业务代码：消除业务层的if-else判断，调用时仅需传递格式类型（如"pdf"），代码更简洁。
支持无侵入扩展：新增TXT导出时，仅需两步：① 新增TxtExporter实现类；② 工厂类中添加一行判断。业务层调用逻辑完全不变，符合"开闭原则"。

3. 两者结合的优势

抽象类解决"规范问题"（确保所有实现类统一接口），工厂模式解决"创建问题"（统一管理对象创建），组合后实现：业务层简洁调用、扩展无侵入、维护成本低、团队协作不踩坑。

五、实际应用场景扩展

除了文档导出，以下业务场景均适用「工厂模式+抽象类」：

支付业务：抽象类BasePay（含pay方法），实现类WechatPay、Alipay，工厂类PayFactory按支付类型创建实例。
物流业务：抽象类BaseLogistics（含pickUp、track方法），实现类ShunfengLogistics、YuantongLogistics，工厂类统一创建。
数据库连接：抽象类BaseDB（含connect、query方法），实现类MysqlDB、RedisDB，工厂类按数据库类型创建连接。

六、结语

核心原则：当业务满足「同类多实现、需统一接口、未来要扩展、创建逻辑复杂」时，优先使用「工厂模式+抽象类」。其本质是通过"定规范（抽象类）+ 统一创建（工厂）"，让代码从"混乱耦合"走向"规范可扩展"，尤其适合中大型项目或团队协作场景。

工厂模式+抽象类 实战指南（基于文档导出业务）