使用classmethod封装类功能而非备用构造函数为何不符合Python风格？

我们可以先对比两种写法的核心差异，模式B相比模式A的优势主要有以下几点：

• 符合@classmethod的约定语义
  Python中@classmethod的通用作用是作为类的扩展构造入口，专门用来生成类实例。把和构造无关的一次性业务逻辑塞进@classmethod会增加读代码的理解成本：其他开发者看到类的classmethod第一反应会认为这是构造方法，需要额外读完逻辑才知道它是执行完就销毁实例的业务函数，不符合常规认知。
• 类的职责边界更清晰
  类本身应该只保留和实例核心能力相关的属性、方法，如果所有和类沾边的上层逻辑都往类里塞，很容易快速膨胀成臃肿的上帝类。模式B把非核心的业务逻辑剥离成独立函数，类的定位更纯粹，维护成本更低。
• 灵活性更高
  独立的顶层函数更容易扩展适配，比如后续你需要让这个逻辑支持其他类的实例，只需要调整函数的入参、逻辑即可。如果绑定成Foo的classmethod，后续要复用的话还需要额外做抽象、继承，反而多了不必要的工作量。
• 贴合Python的设计哲学
  Python之禅明确提到「扁平优于嵌套」，如果一个逻辑不需要依赖类的内部状态、也不需要用到继承体系进行重写，放在顶层命名空间比嵌套在类里更简洁，调用的时候也可以直接写foobaz(xxx)，不需要加类前缀更清爽。

当然两种写法没有绝对的对错，如果你的foobaz逻辑确实和Foo强绑定，且后续需要给Foo的子类继承重写，那用模式A反而更合适，完全可以根据实际场景选择。

# 模式A（自定义classmethod模式）
class Foo():
  def __init__(self, bar):
    self.bar = bar

  def baz(self):
    print(self.bar)

  @classmethod
  def foobaz(cls, bar):
    foo = cls(bar)
    foo.baz()

# 模式B（顶层函数模式）
class Foo():
  def __init__(self, bar):
    self.bar = bar

  def baz(self):
    print(self.bar)

def foobaz(bar):
    foo = Foo(bar)
    foo.baz()

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