Python继承：为父类方法新增参数是否属于反模式？

结论先行 #

这种做法违反里氏替换原则（LSP），属于有风险的反模式，不推荐作为常规设计方式——虽然Python语法上允许，但会破坏父类接口的契约，导致代码在多态场景下直接出错。

核心问题：破坏父类的接口契约 #

父类A定义的run方法约定了「仅需传入steps参数即可调用」，任何依赖A的代码都会基于这个契约编写。但子类B的run要求必须传入第二个参数save，这会导致：

• 当你把B的实例传给一个期望接收A的函数时，该函数调用obj.run(steps)会直接抛出参数不足的异常。
• 这完全违背了多态的核心目的：子类实例可以被安全地当作父类实例使用。

合法且健壮的替代方案 #

1. 给扩展参数设置默认值，保持签名兼容 #

让子类的run方法兼容父类的参数要求，同时支持扩展参数：

from abc import ABC, abstractmethod

class A(ABC):
    @abstractmethod
    def run(self, steps):
        ...

class B(A):
    def run(self, steps, save=False):
        # 基础逻辑 + 可选的保存逻辑
        if save:
            # 执行保存操作
            pass
        # 执行基础run逻辑

这样既满足父类的接口要求，又能在需要时使用扩展参数，同时保证多态场景下的安全性。

2. 新增独立的扩展方法，不重写父类方法 #

把扩展逻辑放到新方法中，明确区分基础接口和扩展功能：

class B(A):
    def run(self, steps):
        # 严格实现父类要求的基础run逻辑
        pass
    
    def run_with_save(self, steps, save):
        # 带保存功能的扩展逻辑
        self.run(steps)
        if save:
            # 执行保存操作
            pass

这种方式更清晰，依赖A的代码用run，需要扩展功能的代码直接使用B的run_with_save，避免接口混淆。

3. 拆分接口，使用接口隔离原则 #

如果不同子类的扩展差异较大，可以拆分出更细的接口：

from abc import ABC, abstractmethod

class Runable(ABC):
    @abstractmethod
    def run(self, steps):
        ...

class Saveable(ABC):
    @abstractmethod
    def save(self):
        ...

class B(Runable, Saveable):
    def run(self, steps):
        # 基础run逻辑
        pass
    
    def save(self):
        # 保存逻辑
        pass

这样依赖基础功能的代码接收Runable，需要保存功能的代码接收Saveable，职责更清晰。

总结 #

Python的动态类型特性允许你写出这种代码，但从面向对象设计的健壮性和可维护性来看，这是一种不良实践。遵循里氏替换原则，保证子类与父类的接口契约兼容，才是更合法、更易维护的设计方式。

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