本文介绍一种基于装饰器和属性检查的 python 解决方案，用于在运行时智能判断子类是否真正实现了特定方法，从而跳过父类中耗时的准备与清理操作，兼顾安全性、可维护性与代码简洁性。
在面向对象设计中，常遇到这样的场景：父类提供一个通用入口方法（如 some_work），内部需执行昂贵的前置准备（如文件加载、网络请求、资源分配）和后置清理，但仅当子类实际重写了核心逻辑方法（如 _do_work）时才应触发这些开销。若子类未重写，直接跳过整段流程才是最优解——既避免性能浪费，又消除错误调用空方法的风险。
上述问题中，简单对比 self._do_work != MyBase._do_work 虽可行，但存在隐患：它依赖方法对象的内存地址比较，在使用 @staticmethod、@classmethod、functools.wraps 或某些装饰器时可能失效；同时，该逻辑侵入业务方法体，破坏单一职责原则。
更优雅的做法是将“是否需要执行”这一决策逻辑提取为可复用的横切关注点。以下推荐两种互补方案：
✅ 方案一：装饰器驱动的条件执行（推荐）
利用 hasattr() 检查子类是否定义了目标方法（注意：hasattr 会触发 __getattr__，但此处用于检查显式定义的方法是安全且语义清晰的），并封装为通用装饰器：
from pathlib import Path
from functools import wraps
def optional_method(submethod_name: str):
"""
装饰器：仅当实例拥有指定名称的方法时，才执行被装饰的方法。
适用于控制昂贵流程的按需触发。
"""
def decorator(method):
@wraps(method)
def wrapper(self, *args, **kwargs):
if hasattr(self, submethod_name) and callable(getattr(self, submethod_name)):
return method(self, *args, **kwargs)
return None # 或 raise NotImplementedError("Subclass must implement " + submethod_name)
return wrapper
return decorator
class MyBase:
@optional_method('_do_work')
def some_work(self):
file = self._do_expensive_preparation()
self._do_work(file) # 此时已确保 _do_work 存在且可调用
self._do_tidy_up()
def _do_expensive_preparation(self) -> Path:
print("⏳ Performing expensive preparation...")
return Path("/tmp/workfile.dat")
def _do_tidy_up(self):
print("? Cleaning up resources...")
class DerivedA(MyBase):
pass # 未实现 _do_work → some_work 直接跳过
class DerivedB(MyBase):
def _do_work(self, file: Path):
print(f"✅ Processing file: {file}")✅ 优势：逻辑解耦、零侵入、类型友好（配合 callable() 校验更健壮）、易于测试和复用。
✅ 方案二：上下文管理器保障资源安全（增强健壮性）
为确保 _do_tidy_up() 在任何情况下（包括异常）都被调用，可将其升级为上下文管理器：
from contextlib import contextmanager
class MyBase:
@contextmanager
def _expensive_context(self):
file = self._do_expensive_preparation()
try:
yield file
finally:
self._do_tidy_up()
@optional_method('_do_work')
def some_work(self):
with self._expensive_context() as file:
self._do_work(file)此时即使 _do_work 抛出异常，_do_tidy_up() 仍会被可靠执行，大幅提升鲁棒性。
⚠️ 注意事项与最佳实践
- 避免 isinstance 或 type(obj).__name__ 判断：它们耦合具体类型，违反开闭原则；
- 慎用 inspect.getsource() 或 __code__ 比较：不可靠（编译优化、动态生成代码等场景失效），且性能差；
- 明确语义：hasattr(...) 检查的是“是否定义”，而非“是否重写”；但对本场景而言，未定义即等价于‘不打算处理’，语义完全一致；
- Python 3.11+ 提示：可结合 typing.override（PEP 698）标注重写意图，辅助静态检查，但运行时仍需 hasattr 判断。
综上，通过 @optional_method 装饰器 + hasattr + 可选的 contextmanager，我们以极简、安全、可扩展的方式解决了“按需触发昂贵逻辑”的核心诉求——无需子类参与协调，不增加维护负担，且天然兼容所有 Python 3.11 特性。
