Python 面向对象设计的反模式总结

__init__只做最小状态赋值，重操作拆为显式方法；优先组合而非滥用继承；方法应无副作用，避免self堆砌临时状态；慎用__getattribute__等魔术方法，以清晰直白为先。

把 __init__ 当成万能初始化入口，忽略职责边界

很多新手一写类就往 __init__ 里塞大量逻辑：读配置、连数据库、加载文件、校验参数……结果对象构造失败时堆栈深、错误难定位，且无法单独测试初始化各环节。

真正该放进去的只有「对象自身状态的最小必要赋值」。其他重操作应拆成显式方法，比如 connect()、load_config()，让调用者按需触发。

• __init__ 中避免 I/O 操作（如 open()、requests.get()）
• 参数校验可保留，但复杂逻辑建议抽到 _validate_params() 并显式调用
• 若必须延迟初始化，用 @Property 或 __getattr__ 做懒加载，别硬塞进 __init__

滥用继承替代组合，导致类爆炸和脆弱基类

看到“XX 是一种 YY”，就立刻写 class XX(YY)，结果基类一改，十几个子类全挂；或者为了复用两行代码，硬造一个单方法父类。

python 的鸭子类型和模块化更适配组合。继承只在「严格满足 is-a 关系 + 需要多态调度」时才成立，比如 FileReader 和 DatabaseReader 共享统一接口 read()，且上层用 isinstance(obj, Reader) 做类型判断。

立即学习“Python免费学习笔记（深入）”；

• 优先用实例变量持有依赖对象（如 self.parser = JSONParser()），而非继承
• 抽象基类（ABC）比普通父类更适合定义契约，避免“空壳父类”污染继承链
• super().__init__() 在多重继承中容易漏调或重复调，不如显式调用目标类方法

把 self 当全局变量用，堆砌状态导致行为不可预测

在方法里不断给 self 赋值临时字段：self._temp_result、self._processed_items……最后谁也说不清哪些字段是对象固有状态，哪些只是某次调用的中间产物。

这会让方法难以复用、并发不安全、序列化出错，还掩盖了真正的数据流——本该是函数输入/输出的东西，被藏进了隐式状态里。

• 方法尽量无副作用：输入参数，返回结果，不修改 self（除非明确是 mutator 方法，如 append()）
• 临时计算结果用局部变量，别存 self；真需要跨方法传递，考虑重构为新类或用 dataclass 封装上下文
• __dict__ 动态增删属性是危险信号，说明设计没收敛，该用 __slots__ 或类型注解约束了

过度设计 __getattribute__ 和 __getattr__，破坏可读性与调试路径

为了“看起来优雅”，用 __getattribute__ 拦截所有属性访问，自动路由到嵌套对象、动态生成方法、甚至查字典 fallback……结果 print(obj.x) 报错时根本看不出 x 是不存在、被拦截了、还是抛了异常。

这些魔术方法不是语法糖，是调试地狱入口。95% 的场景，用显式委托（def x(self): return self._inner.x）或 @property 更直白可靠。

• __getattr__ 只应在「明确知道某些属性缺失时有合理 fallback」时使用（如兼容旧字段名）
• __getattribute__ 几乎不该碰；真要代理，优先用 __getattr__ + 显式 super().__getattribute__()
• ide 和静态检查工具（如 mypy）对魔术方法支持弱，会导致类型提示失效、跳转失效

最难的不是写出能跑的面向对象代码，而是忍住不用那些“看起来很酷”的机制。每次加一个 __ 开头的方法，先问自己：不用它，能不能靠更直白的函数、更清晰的字段、更小的类来解决？