Python中返回类型而非对象的Type Factory使用合理性探讨

我正在研究为具有不同构造函数参数数量的类型实现工厂的方案。多数示例推荐的是返回完全构造好的对象的工厂，这需要工厂来处理不同数量的参数。

由于在Python中类型可以作为返回值，我想知道是否可以实现一种Type Factory：让工厂返回类型而非对象，再调用该类型的构造函数传入合适的参数列表。

以下是一个可运行的最简示例：

#!/usr/bin/env python

class TypeA:
    def __init__(self, arg: int):
        self._data = arg

class TypeB:
    def __init__(self, arg: int, flag: bool = False):
        self._data = arg
        self._flag = flag

def getType(option: str):
    if option == 'A':
        return TypeA
    elif option == 'B':
        return TypeB
    else:
        raise RuntimeError(f"Type '{option}' cannot be resolved")


if __name__ == '__main__':
    objA = getType(option='A')(42)
    objB1 = getType(option='B')(arg=4711, flag=True)
    objB2 = getType(option='B')(arg=815)
    objInvalid = getType(option='C')()

目前我尚未在任何地方看到过相关讨论。（尽管这并非直接解决可变长度参数列表的问题，但我认为动态类型信息在其他非对象创建场景中也可能有用。）

我想了解使用这种返回类型而非对象的工厂变体来创建不同类型是否存在不妥之处，恳请分享看法。

这种返回类型的工厂模式完全可行，甚至在某些场景下非常实用，但也有需要注意的地方：

• 优点：

  • 避免工厂函数需要处理不同类的构造参数，把参数传递的责任交给调用方，减少了工厂的复杂度，尤其适合构造参数差异大的类
  • 调用方可以灵活使用类的构造函数（比如用默认参数、关键字参数），不需要工厂额外封装逻辑
  • 除了创建实例，返回的类型还能用于其他场景，比如类型检查、继承扩展等，正如你提到的动态类型信息的其他用途

• 潜在问题：

  • 调用方认知成本：如果团队习惯了传统工厂返回实例的模式，这种写法可能需要额外说明，否则容易让人困惑，比如看到getType('A')(42)可能需要反应一下这是先拿类再实例化
  • 无法统一初始化逻辑：如果后续需要给所有通过工厂创建的类添加统一的初始化逻辑（比如日志、参数校验），这种模式下就很难做到，因为工厂只返回类型，初始化过程完全由调用方控制
  • 类型提示友好度：如果使用静态类型检查工具（比如mypy），getType返回的类型是Type[TypeA] | Type[TypeB]，调用方在实例化时可能需要额外的类型注解才能获得准确的类型提示，否则编辑器可能无法正确推断实例的类型
  • 异常时机变化：传统工厂在调用时就会抛出创建失败的异常，而这种模式下，getType只负责校验类型是否存在，实例化时的参数错误会在第二次调用时抛出，异常的时机和位置分开了，排查问题时需要注意

总的来说，只要团队内部达成共识，并且你的场景更看重调用灵活性和减少工厂复杂度，这种模式完全可以用，没有本质上的不妥。

内容的提问来源于stack exchange，提问作者twil