1. 这讲要解决什么问题为什么前两讲之后必须讲“三大特性”1.1 一句话回顾前两讲的内容边界在 Python 面向对象编程这个系列的前两篇里我们完成了最基础但也是最关键的铺垫认识了什么是类、什么是对象理解了构造函数__init__怎么初始化实例搞清楚了实例属性、类属性、实例方法、类方法、静态方法之间的差别也亲手写了几个能跑的小例子。如果你是从第一篇跟过来的读者现在应该已经能做到看到一个需求能自然地用类把数据和行为捆在一起能把一个流程里重复的代码抽象成方法能区分什么时候用self.xxx什么时候直接用类名.xxx。但真到了写项目的时候很多人会卡在一个地方——类倒是会写了可写出来的代码要么是一堆互相独立的类要么是继承关系一多就乱成一锅粥。这时候你缺的不是“会定义类”的能力而是“怎么设计类之间的关系”的能力。这一讲我们就来解决这个问题。主题锁定在面向对象三大特性继承、多态、封装。这三个词你可能在面试题里背过无数遍但真正要把它们用在项目里让代码既好扩展又好维护靠背概念是不够的你得知道 Python 里每个特性背后的运行机制知道它们各自的边界在哪知道什么时候用了反而添乱。这篇内容适合谁看两个群体一个是已经把类的基本语法啃完、正准备进入项目阶段的新手另一个是写过一段时间 Python、但总觉得自己的类设计得很别扭、想系统梳理一遍的同学。对于前者这一篇能帮你把概念落到代码上对于后者这一篇里的原理分析和坑位盘点应该能解答你不少“当时没想明白”的疑问。1.2 继承、多态、封装在真实项目里的位置先聊一个观点三大特性不是三个独立的考点它们是一套配合使用的设计手段。封装解决的是“边界问题”——一个对象暴露哪些东西给外面哪些细节不允许外部碰。继承解决的是“复用和扩展问题”——多个类之间有共同逻辑我能不能让它们共用一套代码同时又允许各自差异化扩展。多态解决的是“调用方和实现方解耦问题”——调用方不需要关心当前处理的具体是哪个子类只要确保它支持某个方法就能统一调用。用一个生活化的比喻你开一间餐厅后厨有洗菜、切菜、炒菜三个岗位。封装相当于给每个岗位划分了权限洗菜的不需要知道炒菜的用多少油继承相当于“后厨员工”这个通用模板不管是洗菜工还是炒菜工都要打卡、穿工作服、遵守卫生规范多态相当于店长只需要说“把这道菜做了”不用管具体是哪个岗位的人执行反正接到指令的人知道怎么做。项目里的场景也是一样的。你需要一组类它们业务上确实是“父子关系”那就用继承抽出公共逻辑你需要对不同类型的对象做同一件事但希望调用代码不关心具体类型那就让它们实现同名方法用多态统一处理你想把内部状态保护起来只暴露受控的访问途径那就用封装。这三者组合起来你的代码结构才会从“一堆能跑的脚本”变成“一个有层次的设计”。1.3 这篇的结构安排我的规划是这样的先讲继承因为它是三大特性的地基再讲多态它会大量依赖继承或接口约定建立起来的类型关系接着讲封装把对象边界的控制手段补全然后加一个综合实战把三个特性用在同一个完整例子里最后是常见问题排查——这一部分我会把这些年自己写代码和带新人时遇到的典型坑位整理成清单你可以直接当速查表用。如果你只对某一块感兴趣也可以直接跳到对应章节但坦白说三个特性之间的联动性很强连着读完理解会更深。2. 继承不只是“子类复用父类”这么简单2.1 从一个几乎人人都会踩的坑说起先看一段几乎所有 Python 教程都会出现的例子class Animal: def __init__(self, name): self.name name def eat(self): print(f{self.name} is eating) class Dog(Animal): def bark(self): print(f{self.name} is barking) dog Dog(旺财) dog.eat() # 输出旺财 is eating dog.bark() # 输出旺财 is barking这段代码很正确但它只展示了继承最浅的一面子类“继承了”父类的方法和属性可以直接调用。真正的坑在哪儿在于很多新手会认为“子类里没写__init__就自动继承了父类的__init__”。这句话在单继承的简单场景下凑巧是对的但一旦你给子类加了自定义的__init__却不调用super().__init__()父类的初始化逻辑就白写了。class Dog(Animal): def __init__(self, name, breed): self.breed breed dog Dog(旺财, 中华田园犬) print(dog.name) # AttributeError: Dog object has no attribute name这个报错信息很多初学者都见过头脑正常的第一反应是“我不是继承了 Animal 吗为什么不给我初始化 name”原因在于Dog.__init__一旦自己定义了就会完全覆盖父类的__init__Python 不会自动帮你把父类的__init__也调用一遍。你需要显式地补上这一层逻辑。修复起来其实就一行class Dog(Animal): def __init__(self, name, breed): super().__init__(name) self.breed breed这一行super().__init__(name)的作用是调用父类Animal的初始化逻辑把name设置好然后再补充子类自己的属性。这个坑我见过太多次了。每次带新人第一课我都会专门强调继承的核心是“代际初始化要层层传递”。父类的__init__处理父类负责的属性子类的__init__负责处理子类新增的属性子类的__init__第一行必须考虑要不要调用super().__init__()把父类的初始化接力下去。2.2 方法解析顺序MRO到底是怎么算出来的聊到多重继承就绕不开 Python 里的一个核心机制MROMethod Resolution Order方法解析顺序。简单理解MRO 就是“当你调用一个方法时Python 按照什么顺序去各个类里找这个方法”。单继承的场景下这个顺序很直观先从子类自己找找不到就去父类找父类没有再去父类的父类找一路顶上直到 object。但多重继承一出现事情就复杂了class A: def who_am_i(self): print(I am A) class B(A): def who_am_i(self): print(I am B) class C(A): def who_am_i(self): print(I am C) class D(B, C): pass d D() d.who_am_i()问你一个问题d.who_am_i()会输出什么如果你觉得是 “I am A”那就搞错了。答案是 “I am B”。要理解为什么你需要看一眼D的 MRO 列表print(D.__mro__) # (class __main__.D, class __main__.B, class __main__.C, class __main__.A, class object)Python 查找who_am_i时会严格按照这个顺序去找先D自己没有然后B有命中结束。B定义了同名方法所以它优先于A和C。这个顺序并不是随机排的它遵循的是 C3 线性化算法。你不一定需要背下 C3 的实现细节但至少要理解它的核心约束我概括成三条子类永远排在父类前面。一个类出现在列表里的位置取决于它在继承声明里的顺序比如class D(B, C)B 就在 C 前面。如果多个类都继承自同一个基类那个基类只会出现一次并且会放在所有需要它的类之后。我给你推导一下D(B, C)的 MRO 为什么是D - B - C - A - object先取B因为它是D的左父类。B自己的 MRO 是B - A - object。再取C因为它是D的右父类。C自己的 MRO 是C - A - object。合并时要满足A不能出现在B和C之前因为B和C都继承自A子类优先。于是合并的结果就是D - B - C - A - object。A只出现一次且排在B、C之后。这个机制的实际价值在于你写代码的时候不用每次手动推理 MRO但当你遇到多重继承里方法被“莫名其妙”地拦截、或者看到那种“我明明没在子类里定义这个方法为什么调出来的结果跟预期不一样”的 bug 时你要知道先去看__mro__看 Python 到底按什么顺序找方法。MRO 另一个实际用途是处理“钻石继承”。也就是说class D(B, C)而B和C都继承自A这时一个D实例的构建过程会走到几次A.__init__答案是只走一次。C3 线性化保证了公共基类的初始化逻辑不会被执行两遍这个特性在多重继承的初始化场景下非常重要。2.3 super() 的正确用法和错误姿势现在我们来专门说说super()。它可能是 Python 里最被误用的内置函数之一。很多初学者理解super()是“调用父类的方法”这个说法在单继承下凑合能用但如果你的类处于多重继承链里super()执行时找的并不是字面意义上“声明里的那个父类”而是按照 MRO 顺序往后找下一个类。严格来说super()做的事是返回一个代理对象这个代理将方法调用转发给 MRO 中当前类的下一个类。举个例子你就明白了class A: def who(self): print(A) super().who() class B: def who(self): print(B) class C(A, B): pass c C() c.who()输出是什么我们按 MRO 来推。C.__mro__是C - A - B - object。调用c.who()先在C里找不到于是到A打印 “A”然后执行super().who()——这里的super()是在A的上下文中它按 MRO 找到A的下一个类也就是B于是调用B.who打印 “B”。所以输出是A B如果你不理解 super 是“按 MRO 前进”而不是“调用父类”你会觉得这段代码匪夷所思A 的父类不是 object 吗为什么 A 里的 super 会调到 B 去对这正是super()最不直观的地方也是 Python 与很多静态语言不同的设计哲学它把方法查找从“类的静态继承链”提升到了“运行时 MRO 动态链”。在实际编码里super()最常见的正确用途就是我前面讲到的在子类的__init__里调用它把初始化任务接力下去。此外在__str__、__repr__、save()这类需要“先执行父类的逻辑再补充子类逻辑”的方法里也非常常用。错误姿势也很多我举两个典型第一个错误姿势是super()不带参数乱用。在类内部直接写super()是 Python 3 的便捷写法它自动帮你传入了当前类和self。如果在类外面或者类方法里生硬地使用会直接报错。比如def func(): super() # RuntimeError: super(): no arguments第二个错误姿势是误解了它的“接力”性质。如果在多重继承的某一个类里super().xxx()一直往 MRO 后面找但后面的类里没有你要调的方法你会得到一个AttributeError。所以写多重继承时最好保证参与 MRO 链的类里面都有那个同名方法哪怕是当作兜底的空实现。2.4 什么时候应该用继承什么时候应该用组合聊到这里我觉得有必要泼一盆冷水继承虽然好但真的不要滥用。我见过太多类设计明明类之间没有“是一个”的关系硬用继承去套最后跑到调用层各种别扭。判断要不要用继承最经典的标准就一条问自己“子类和父类之间是不是 is-a 关系”。狗是一条动物是 is-a适合继承。员工有手机是 has-a不应该让Employee继承Phone而应该在Employee里加一个self.phone Phone(...)属性——这就是组合。组合与继承都是代码复用的手段但组合更灵活。继承在编译期或者说类定义时就固定了类的结构而组合把组件作为属性注入运行时可以随时替换。举一个我实际做过的场景当时要写一组报表类有 PDF 报表、Excel 报表、CSV 报表。它们确实有共同逻辑——从数据库取数、做数据清洗、计算汇总指标——一开始我准备建一个BaseReport类三个子类继承它各自实现generate()。这个设计没问题但如果后来产品经理告诉我“同一份数据可能需要同时导出 PDF 和 Excel 两种格式”继承的做法就有点僵了因为一个类只能继承一个父类总不能搞个PDFExcelReport继承两个父类吧——这在语义上就很别扭。改成组合以后逻辑变成了取数和清洗是独立的DataFetcher类生成 PDF 是PDFRenderer类生成 Excel 是ExcelRenderer类报表主类里面self.fetcher DataFetcher(...)、self.renderer PDFRenderer(...)根据不同需求注入不同的渲染器。灵活度一下子高了很多新增格式也不用动主类逻辑。我的经验是代码复用不超过两层的时候继承很顺手一旦层级深了或者一个类会从多个维度变化优先考虑组合。这条建议值得你写进自己的编码规范里。3. 多态Python 的多态和 Java 不一样3.1 鸭子类型——Python 多态的真正实现方式在 Java 或 C 里多态通常意味着一个基类类型的引用指向子类对象调用同名方法时程序会根据对象的真实类型去执行对应版本的实现。这个机制建立在“显式的类型继承关系”上。Python 不一样。Python 的多态核心是鸭子类型duck typing——“如果它走起来像鸭子、叫起来像鸭子那它就是鸭子”。换句话说Python 不关心一个对象是否继承了某个特定基类它只关心这个对象有没有你要调用的那个方法。class Dog: def sound(self): return 汪 class Cat: def sound(self): return 喵 class Car: def sound(self): return 嘀嘀 def make_sound(obj): print(obj.sound()) make_sound(Dog()) # 汪 make_sound(Cat()) # 喵 make_sound(Car()) # 嘀嘀这三个类之间没有任何继承关系但它们都有sound()方法所以make_sound函数就能接受任何“会叫”的对象。这就是多态在 Python 里的朴素体现调用方只依赖对象的接口不依赖对象的类型。这对设计有什么影响呢它意味着 Python 里“多态”的约束是隐式的。好处是你写出来的代码非常灵活新增一个类只要方法名对得上老的调用方代码一行都不用改坏处是如果不小心等运行时才发现对象缺少了某个方法。所以 Python 社区里有很多“协议”的概念比如__iter__、__enter__、__len__。所谓“实现了某个协议”本质就是说“我有这个方法你可以放心调用”。这是鸭子类型在 Python 里最高频的应用场景。3.2 用抽象基类给多态“画条线”鸭子类型太自由了自由到有时候团队协作时容易失控。比如同事小张写了一个函数约定传入的对象要有read()方法但另一个同事传进来一个没有read()的对象结果代码运行到那个位置才崩溃大家排查了半天。如果你希望“结构上就保证传入的对象一定满足某个接口”标准库里的abc模块能帮你做到。抽象基类Abstract Base ClassABC允许你定义一组强制子类实现的方法凡是继承了抽象基类但没有实现全部抽象方法的类根本无法实例化。from abc import ABC, abstractmethod class Shape(ABC): abstractmethod def area(self): pass class Rectangle(Shape): def __init__(self, width, height): self.width width self.height height def area(self): return self.width * self.height # 尝试实例化一个没有实现 area 的类会直接报错 class Circle(Shape): pass c Circle() # TypeError: Cant instantiate abstract class Circle # with abstract method area这个机制不是要替代鸭子类型它是给“鸭子类型”增加了一道编译期更准确地说是实例化期的检查。适合用在那些接口约定非常稳定的场景比如框架内部定义插件接口或者团队里多人协作时明确“你实现的模块必须提供这些方法”。但也要提醒一句别把所有类都做成抽象基类那就陷入“过度设计”了。Python 的哲学是灵活优先不是所有场景都需要提前约束。我自己一般遵循这样的原则写库或框架、面向外部使用者时用抽象基类明确接口项目内部几个类之间的临时协作鸭子类型完全够用加抽象基类反而拖慢节奏。3.3 多态让代码消除 if-else 的实际案例多态最直接的价值体现在消除大量的if-else或elif分支。想象一个订单折扣系统不同的用户等级有不同的折扣规则def get_discount(user_type): if user_type normal: return 0.95 elif user_type vip: return 0.9 elif user_type svip: return 0.8 else: return 1.0这个函数用起来没问题。但每次新增一个用户等级你都要回来改这个函数——这是典型的“开闭原则”违反案例代码对扩展没有天然地“打开”。用多态重构一下class User: def get_discount(self): return 1.0 class NormalUser(User): def get_discount(self): return 0.95 class VIPUser(User): def get_discount(self): return 0.9 class SVIPUser(User): def get_discount(self): return 0.8调用方的代码变成了def apply_discount(user, price): return price * user.get_discount()新增一个用户等级时只需要新写一个User的子类不需要动apply_discount。这就是多态对代码结构最实质的改善把“针对不同类型做不同处理”的逻辑打散到各个类内部调用方保持稳定。我见过很多老项目里的巨型if-elif链动辄几十个分支。那种代码不是不能跑但是每次需求变动都要小心翼翼地在某个分支上修来修去测试面特别大。用多态重构之后每次改动收敛到一个类里风险和改动范围都大大缩小。这个经验是我在多态上收获最大的实际应用。4. 封装私有属性、保护属性与 property 的边界4.1 单下划线和双下划线的真实区别封装在 Python 里是一种“约定优先于强制”的机制它不像 Java 那样用private关键词把属性完全锁死。先记住这个总基调然后我们看两个下划线约定。单下划线开头_attribute表示“这是内部属性外部不应该直接访问”。它只是一个约定如果你非要在外部访问Python 不会拦你代码也能正常运行。它更多是写给人的提示看到_name你就知道这个属性不是公共接口的一部分最好不要碰。双下划线开头__attribute就稍微复杂一点了。它触发了 Python 的名称改写name mangling机制在类定义内部__attribute会被改写成_ClassName__attribute。这不是为了绝对的安全而是为了避免在继承场景下子类的同名属性与父类冲突。class Father: def __init__(self): self.__money 1000 class Son(Father): def __init__(self): super().__init__() self.__money 500 s Son() print(s.__dict__) # {_Father__money: 1000, _Son__money: 500}看到没父类和子类各自定义了一个__money但因为名称改写它们实际是_Father__money和_Son__money互不干扰。如果你用单下划线_money子类的赋值就会把父类的属性覆盖掉。有人在网上说“双下划线就是私有不能访问”其实不准确。如果你知道改写规则还是可以强行访问的比如s._Father__money。所以我的态度一直很明确双下划线的主要价值是规避继承冲突不是用来做严格保密。真正需要藏起来的信息应该放在安防设计里考虑而不是靠语言特性。4.2 property 的工作原理与常见用途property是 Python 封装的灵魂。它让你可以在不改变外部调用方式的情况下把“访问一个属性”变成“执行一段逻辑”。先看一段典型场景。假设有个用户类直接暴露属性age外部可以随便设成负数class User: def __init__(self, name, age): self.name name self.age age u User(小明, 18) u.age -5 # 没有报错但明显不合逻辑加上property之后你可以把age从“直接存取的属性”改成“由逻辑控制的属性”class User: def __init__(self, name, age): self.name name self._age age property def age(self): return self._age age.setter def age(self, value): if value 0: raise ValueError(age cannot be negative) self._age value现在当外部执行u.age -5时会走setter里的校验逻辑直接抛异常。而读取u.age则走getter。这个特性在项目里最常见的用途有几个一是校验就像上面这个例子。设置属性前检查值的合法性避免脏数据进入对象内部。二是计算属性。有些“属性”不是存储在实例里的而是由其他数据实时算出来的。比如一个订单类class Order: def __init__(self, price, quantity): self.price price self.quantity quantity property def total(self): return self.price * self.quantitytotal看起来是个属性外部调用是order.total不需要加括号但它其实是实时计算的。这样调用方写起来很自然不用区分“哪些是存的哪些是算的”。三是向后兼容。项目初期User类直接暴露了age属性很多代码都在用u.age。后来需求变了你希望在读取age时顺便做别的操作如果不希望改所有调用方的代码就可以把age改造成property外部代码一行都不用动只有内部逻辑升级了。这种“最小改动就能升级接口”的能力在维护老项目时价值巨大。4.3 不要过度封装什么时候该直接暴露属性有一类同学学了封装之后变得特别激进所有属性全都加下划线所有访问都写 setter/getter最后代码又臭又长。这其实走偏了。Python 的设计哲学里有一条叫“我们都要对自己的行为负责”。如果一个属性就是纯粹的存取不需要校验、不需要计算、不需要控制访问那就直接暴露它不要为了写 setter/getter 而写。# 过度封装 class Point: def __init__(self, x, y): self._x x self._y y property def x(self): return self._x x.setter def x(self, value): self._x value property def y(self): return self._y y.setter def y(self, value): self._y value这段代码没有任何问题但它也什么都没解决。字段就是两个坐标点不需要约束直接写self.x x、self.y y就是最清晰的代码。那什么时候值得封装三条标准赋值或读取时需要有额外逻辑比如校验、换算、记录日志。属性的值不是直接存储的而是由其他状态计算得到的。你预期未来可能加逻辑现在先用property给调用方一个稳定接口防止以后外部代码大面积改调用方式。我个人的习惯是一开始尽量保持属性公开等真的出现约束需求了再加property。Python 的蛇形命名和动态特性决定了从公开属性改成property的成本非常低外部调用代码几乎不用动所以没必要一开始就层层包裹。过早地加 getter/setter只会让代码读起来冗余还不利于新手理解。5. 实战拿“员工薪资系统”把三大特性串起来5.1 需求与类设计概念聊得再多不落地都是空中楼阁。我们来做一个小而完整的实战员工薪资系统。需求是这样的公司有普通员工、经理、实习生三种角色。普通员工拿固定月薪经理除了固定月薪还有项目奖金实习生按小时计费。我们需要一个统一的方法能够计算任意员工的总收入并且在展示信息时能区分不同角色。这个需求看起来简单但足够展示继承、多态、封装三个特性的配合。先看类设计基类Employee包含所有员工都有的公共信息姓名、工号以及一个待子类实现的计算薪资方法get_pay()。子类Manager继承Employee添加bonus属性重写get_pay()。子类Intern继承Employee添加hourly_rate和hours属性重写get_pay()。用一个统一的调用函数接受任意员工对象打印员工信息和薪资——这个函数不用关注具体是什么子类这就是多态。5.2 完整代码实现与逐段讲解先写基类。注意我用property把name和emp_id包了一层主要是演示封装的用法from abc import ABC, abstractmethod class Employee(ABC): def __init__(self, name, emp_id): self._name name self._emp_id emp_id property def name(self): return self._name property def emp_id(self): return self._emp_id abstractmethod def get_pay(self): 计算员工应发薪资子类必须实现 pass def show_info(self): return f员工{self.name}工号{self.emp_id}这里Employee继承自ABC并且get_pay加了abstractmethod装饰器这意味着不能直接实例化员工必须由子类实现get_pay才能实例化。这个设计很合理一个没有具体薪资计算规则的“通用员工”不应该能实例化。接着写子类class Manager(Employee): def __init__(self, name, emp_id, base_salary, bonus): super().__init__(name, emp_id) self.base_salary base_salary self.bonus bonus def get_pay(self): return self.base_salary self.bonus class Intern(Employee): def __init__(self, name, emp_id, hourly_rate, hours): super().__init__(name, emp_id) self.hourly_rate hourly_rate self.hours hours def get_pay(self): return self.hourly_rate * self.hoursManager和Intern都通过super().__init__(name, emp_id)把基类负责的初始化接力下去然后各自保存自己的新增字段并且各自实现了get_pay()。注意两个子类都没有定义show_info但它们都能调用show_info这就是继承对公共逻辑的复用。现在写一个统一处理员工信息的函数def print_pay(employee): print(employee.show_info()) print(f实发薪资{employee.get_pay()} 元) manager Manager(张经理, M001, 15000, 5000) intern Intern(小李, I001, 25, 80) for emp in [manager, intern]: print_pay(emp)这里就是多态发挥威力的时候。print_pay函数根本不需要知道传入的是Manager还是Intern只要这个对象有show_info()和get_pay()方法就能正常工作。以后新增一个岗位角色只要它是Employee的子类且实现了get_pay()这个函数无需任何修改。5.3 运行结果与设计复盘运行上面这段代码输出是员工张经理工号M001 实发薪资20000 元 员工小李工号I001 实发薪资2000 元现在复盘一下这个例子里的设计继承用在哪里Manager和Intern复用了Employee的name、emp_id、show_info。多态用在哪里print_pay统一调用get_pay()不同子类给出不同实现。封装用在哪里name和emp_id被包成property外部不能直接改保证了员工基本信息的安全。这个例子的最后我建议你做一个小练习新增一个Director角色薪资规则是年薪 股权折算成月收入。你试试只需要新增一个类、不改任何现有代码整个系统就能跑起来。做成了这个题你就真正理解了面向对象设计的意义——新的需求来了老的代码稳如泰山你只需要在文件的末尾追加一段新类。6. 常见问题与排查技巧实录6.1 五个高频报错和解决办法我在带项目时总结过一套“OOP 高频报错速查”这里整理给你。第一个是AttributeError: XXX object has no attribute yyy。这个报错十次有八次出在__init__里。要么是忘了调用super().__init__()父类初始化的属性没有设置要么是属性名拼写不一致比如self.name写成了self.nmae。排查办法很简单打印实例的__dict__属性看看这个对象里到底存了哪些键。print(obj.__dict__)第二个是TypeError: Cant instantiate abstract class XXX with abstract method yyy。说明你继承了一个抽象基类但没有实现里面的抽象方法。检查一下是不是漏了abstractmethod对应的方法或者方法名是否与父类一致。这里特别容易遇到的一个问题是Area()和area()大小写不一致Python 方法名是区分大小写的写错了就等于没实现。第三个是TypeError: super() takes at least 1 argument (0 given)。这个基本可以判定是 Python 2 的习惯混到 Python 3 里了。Python 3 的类内部直接写super()就行不用传参传入类名和实例反而是多此一举。检查一下文件头有没有from __future__ import ...之类的历史遗留代码。第四个是多重继承里__init__被调用了多次导致属性被重复设置或计算错误。这个问题的根源往往是某个中间类里没有正确调用super()把初始化链条打断了。解决办法是链路上的每个类都写super().__init__(...)保持 MRO 链条的完整。第五个是明明在子类里重写了方法调用时却还是走了父类的实现。这种情况先别怀疑 Python先看是不是方法名写错了再看__mro__的顺序最后看有没有在子类里因为拼写把方法写成了别的名字。对 Python 而言run和run_是两个完全不同的方法前者重写、后者是新增不会自动帮你建立“语义相同”的关联。6.2 三个典型的逻辑坑除了报错还有三个逻辑层面的坑代码不报错但行为完全不符合预期。第一个是可变默认参数。这个坑不止发生在类里但类方法里特别常见class ShoppingCart: def __init__(self, items[]): self.items items cart1 ShoppingCart() cart1.items.append(apple) cart2 ShoppingCart() print(cart2.items) # [apple]你没看错cart2的购物车里也出现了苹果。原因是默认参数items[]在函数定义时只会被创建一次所有实例共享同一个列表对象。正确写法是itemsNone然后在__init__里判断def __init__(self, itemsNone): self.items items if items is not None else []第二个坑是动态添加新属性导致property失效。比如你给了property的 getter但没有写 setter外部执行obj.age 20会报AttributeError: cant set attribute。如果你希望属性只读这是预期行为如果你希望可写记得写age.setter。我还见过更隐蔽的版本类里定义了property但实例化后某个地方直接给实例绑定了同名属性下次访问时命中实例属性property反而不生效了。遇到这种问题打印obj.__dict__就能一眼看穿。第三个坑是重写方法时忘了super()调用导致父类的关键逻辑被“悄悄绕过”。这很常见尤其是初学者重写__init__、save这类方法时写完子类的逻辑直接return把父类的关键初始化步骤跳过运行一段时间后才在某处爆出状态不一致。我的建议是子类重写方法时先想一想这个方法是“完全替换父类逻辑”还是“在父类逻辑基础上做扩展”后者必须在方法开头调用super().xxx()。这是 OOP 设计里一个极其重要的习惯。6.3 调试建议怎么一步步定位 OOP 问题最后分享一套我排查类相关问题时的固定套路。第一步先把对象“解剖”开看内部状态。不管报错还是不报错先打印obj.__dict__看看对象里实际存了哪些属性。这个操作能过滤掉一半的“属性不存在”和“属性值不对”类问题。第二步看类型和继承链。用type(obj)确认对象的实际类型用obj.__class__.__mro__查看方法查找顺序。我经常遇到的一种情况是对象看起来是SubClass实际却是另一个类因为在某处被重新赋值了。第三步缩小范围做最小复现。如果问题出在一个大类的复杂协作里我会写一个 10 行以内的最小脚本把相关的几个类抽出来单独测试。很多时候问题不是出在类本身而是出在类与类之间的协作顺序上。比如一个组件没有被正确注入一个依赖没有提前初始化这些都要靠最小复现脚本一步一步验证。这三个步骤说起来简单但投入回报率极高能帮你从“瞎猜”变成“按证据找问题”。我在任何项目里调试面向对象代码都是这个流程。 Python面向对象三大特性：继承、多态与封装实战解析
1. 这讲要解决什么问题为什么前两讲之后必须讲“三大特性”1.1 一句话回顾前两讲的内容边界在 Python 面向对象编程这个系列的前两篇里我们完成了最基础但也是最关键的铺垫认识了什么是类、什么是对象理解了构造函数__init__怎么初始化实例搞清楚了实例属性、类属性、实例方法、类方法、静态方法之间的差别也亲手写了几个能跑的小例子。如果你是从第一篇跟过来的读者现在应该已经能做到看到一个需求能自然地用类把数据和行为捆在一起能把一个流程里重复的代码抽象成方法能区分什么时候用self.xxx什么时候直接用类名.xxx。但真到了写项目的时候很多人会卡在一个地方——类倒是会写了可写出来的代码要么是一堆互相独立的类要么是继承关系一多就乱成一锅粥。这时候你缺的不是“会定义类”的能力而是“怎么设计类之间的关系”的能力。这一讲我们就来解决这个问题。主题锁定在面向对象三大特性继承、多态、封装。这三个词你可能在面试题里背过无数遍但真正要把它们用在项目里让代码既好扩展又好维护靠背概念是不够的你得知道 Python 里每个特性背后的运行机制知道它们各自的边界在哪知道什么时候用了反而添乱。这篇内容适合谁看两个群体一个是已经把类的基本语法啃完、正准备进入项目阶段的新手另一个是写过一段时间 Python、但总觉得自己的类设计得很别扭、想系统梳理一遍的同学。对于前者这一篇能帮你把概念落到代码上对于后者这一篇里的原理分析和坑位盘点应该能解答你不少“当时没想明白”的疑问。1.2 继承、多态、封装在真实项目里的位置先聊一个观点三大特性不是三个独立的考点它们是一套配合使用的设计手段。封装解决的是“边界问题”——一个对象暴露哪些东西给外面哪些细节不允许外部碰。继承解决的是“复用和扩展问题”——多个类之间有共同逻辑我能不能让它们共用一套代码同时又允许各自差异化扩展。多态解决的是“调用方和实现方解耦问题”——调用方不需要关心当前处理的具体是哪个子类只要确保它支持某个方法就能统一调用。用一个生活化的比喻你开一间餐厅后厨有洗菜、切菜、炒菜三个岗位。封装相当于给每个岗位划分了权限洗菜的不需要知道炒菜的用多少油继承相当于“后厨员工”这个通用模板不管是洗菜工还是炒菜工都要打卡、穿工作服、遵守卫生规范多态相当于店长只需要说“把这道菜做了”不用管具体是哪个岗位的人执行反正接到指令的人知道怎么做。项目里的场景也是一样的。你需要一组类它们业务上确实是“父子关系”那就用继承抽出公共逻辑你需要对不同类型的对象做同一件事但希望调用代码不关心具体类型那就让它们实现同名方法用多态统一处理你想把内部状态保护起来只暴露受控的访问途径那就用封装。这三者组合起来你的代码结构才会从“一堆能跑的脚本”变成“一个有层次的设计”。1.3 这篇的结构安排我的规划是这样的先讲继承因为它是三大特性的地基再讲多态它会大量依赖继承或接口约定建立起来的类型关系接着讲封装把对象边界的控制手段补全然后加一个综合实战把三个特性用在同一个完整例子里最后是常见问题排查——这一部分我会把这些年自己写代码和带新人时遇到的典型坑位整理成清单你可以直接当速查表用。如果你只对某一块感兴趣也可以直接跳到对应章节但坦白说三个特性之间的联动性很强连着读完理解会更深。2. 继承不只是“子类复用父类”这么简单2.1 从一个几乎人人都会踩的坑说起先看一段几乎所有 Python 教程都会出现的例子class Animal: def __init__(self, name): self.name name def eat(self): print(f{self.name} is eating) class Dog(Animal): def bark(self): print(f{self.name} is barking) dog Dog(旺财) dog.eat() # 输出旺财 is eating dog.bark() # 输出旺财 is barking这段代码很正确但它只展示了继承最浅的一面子类“继承了”父类的方法和属性可以直接调用。真正的坑在哪儿在于很多新手会认为“子类里没写__init__就自动继承了父类的__init__”。这句话在单继承的简单场景下凑巧是对的但一旦你给子类加了自定义的__init__却不调用super().__init__()父类的初始化逻辑就白写了。class Dog(Animal): def __init__(self, name, breed): self.breed breed dog Dog(旺财, 中华田园犬) print(dog.name) # AttributeError: Dog object has no attribute name这个报错信息很多初学者都见过头脑正常的第一反应是“我不是继承了 Animal 吗为什么不给我初始化 name”原因在于Dog.__init__一旦自己定义了就会完全覆盖父类的__init__Python 不会自动帮你把父类的__init__也调用一遍。你需要显式地补上这一层逻辑。修复起来其实就一行class Dog(Animal): def __init__(self, name, breed): super().__init__(name) self.breed breed这一行super().__init__(name)的作用是调用父类Animal的初始化逻辑把name设置好然后再补充子类自己的属性。这个坑我见过太多次了。每次带新人第一课我都会专门强调继承的核心是“代际初始化要层层传递”。父类的__init__处理父类负责的属性子类的__init__负责处理子类新增的属性子类的__init__第一行必须考虑要不要调用super().__init__()把父类的初始化接力下去。2.2 方法解析顺序MRO到底是怎么算出来的聊到多重继承就绕不开 Python 里的一个核心机制MROMethod Resolution Order方法解析顺序。简单理解MRO 就是“当你调用一个方法时Python 按照什么顺序去各个类里找这个方法”。单继承的场景下这个顺序很直观先从子类自己找找不到就去父类找父类没有再去父类的父类找一路顶上直到 object。但多重继承一出现事情就复杂了class A: def who_am_i(self): print(I am A) class B(A): def who_am_i(self): print(I am B) class C(A): def who_am_i(self): print(I am C) class D(B, C): pass d D() d.who_am_i()问你一个问题d.who_am_i()会输出什么如果你觉得是 “I am A”那就搞错了。答案是 “I am B”。要理解为什么你需要看一眼D的 MRO 列表print(D.__mro__) # (class __main__.D, class __main__.B, class __main__.C, class __main__.A, class object)Python 查找who_am_i时会严格按照这个顺序去找先D自己没有然后B有命中结束。B定义了同名方法所以它优先于A和C。这个顺序并不是随机排的它遵循的是 C3 线性化算法。你不一定需要背下 C3 的实现细节但至少要理解它的核心约束我概括成三条子类永远排在父类前面。一个类出现在列表里的位置取决于它在继承声明里的顺序比如class D(B, C)B 就在 C 前面。如果多个类都继承自同一个基类那个基类只会出现一次并且会放在所有需要它的类之后。我给你推导一下D(B, C)的 MRO 为什么是D - B - C - A - object先取B因为它是D的左父类。B自己的 MRO 是B - A - object。再取C因为它是D的右父类。C自己的 MRO 是C - A - object。合并时要满足A不能出现在B和C之前因为B和C都继承自A子类优先。于是合并的结果就是D - B - C - A - object。A只出现一次且排在B、C之后。这个机制的实际价值在于你写代码的时候不用每次手动推理 MRO但当你遇到多重继承里方法被“莫名其妙”地拦截、或者看到那种“我明明没在子类里定义这个方法为什么调出来的结果跟预期不一样”的 bug 时你要知道先去看__mro__看 Python 到底按什么顺序找方法。MRO 另一个实际用途是处理“钻石继承”。也就是说class D(B, C)而B和C都继承自A这时一个D实例的构建过程会走到几次A.__init__答案是只走一次。C3 线性化保证了公共基类的初始化逻辑不会被执行两遍这个特性在多重继承的初始化场景下非常重要。2.3 super() 的正确用法和错误姿势现在我们来专门说说super()。它可能是 Python 里最被误用的内置函数之一。很多初学者理解super()是“调用父类的方法”这个说法在单继承下凑合能用但如果你的类处于多重继承链里super()执行时找的并不是字面意义上“声明里的那个父类”而是按照 MRO 顺序往后找下一个类。严格来说super()做的事是返回一个代理对象这个代理将方法调用转发给 MRO 中当前类的下一个类。举个例子你就明白了class A: def who(self): print(A) super().who() class B: def who(self): print(B) class C(A, B): pass c C() c.who()输出是什么我们按 MRO 来推。C.__mro__是C - A - B - object。调用c.who()先在C里找不到于是到A打印 “A”然后执行super().who()——这里的super()是在A的上下文中它按 MRO 找到A的下一个类也就是B于是调用B.who打印 “B”。所以输出是A B如果你不理解 super 是“按 MRO 前进”而不是“调用父类”你会觉得这段代码匪夷所思A 的父类不是 object 吗为什么 A 里的 super 会调到 B 去对这正是super()最不直观的地方也是 Python 与很多静态语言不同的设计哲学它把方法查找从“类的静态继承链”提升到了“运行时 MRO 动态链”。在实际编码里super()最常见的正确用途就是我前面讲到的在子类的__init__里调用它把初始化任务接力下去。此外在__str__、__repr__、save()这类需要“先执行父类的逻辑再补充子类逻辑”的方法里也非常常用。错误姿势也很多我举两个典型第一个错误姿势是super()不带参数乱用。在类内部直接写super()是 Python 3 的便捷写法它自动帮你传入了当前类和self。如果在类外面或者类方法里生硬地使用会直接报错。比如def func(): super() # RuntimeError: super(): no arguments第二个错误姿势是误解了它的“接力”性质。如果在多重继承的某一个类里super().xxx()一直往 MRO 后面找但后面的类里没有你要调的方法你会得到一个AttributeError。所以写多重继承时最好保证参与 MRO 链的类里面都有那个同名方法哪怕是当作兜底的空实现。2.4 什么时候应该用继承什么时候应该用组合聊到这里我觉得有必要泼一盆冷水继承虽然好但真的不要滥用。我见过太多类设计明明类之间没有“是一个”的关系硬用继承去套最后跑到调用层各种别扭。判断要不要用继承最经典的标准就一条问自己“子类和父类之间是不是 is-a 关系”。狗是一条动物是 is-a适合继承。员工有手机是 has-a不应该让Employee继承Phone而应该在Employee里加一个self.phone Phone(...)属性——这就是组合。组合与继承都是代码复用的手段但组合更灵活。继承在编译期或者说类定义时就固定了类的结构而组合把组件作为属性注入运行时可以随时替换。举一个我实际做过的场景当时要写一组报表类有 PDF 报表、Excel 报表、CSV 报表。它们确实有共同逻辑——从数据库取数、做数据清洗、计算汇总指标——一开始我准备建一个BaseReport类三个子类继承它各自实现generate()。这个设计没问题但如果后来产品经理告诉我“同一份数据可能需要同时导出 PDF 和 Excel 两种格式”继承的做法就有点僵了因为一个类只能继承一个父类总不能搞个PDFExcelReport继承两个父类吧——这在语义上就很别扭。改成组合以后逻辑变成了取数和清洗是独立的DataFetcher类生成 PDF 是PDFRenderer类生成 Excel 是ExcelRenderer类报表主类里面self.fetcher DataFetcher(...)、self.renderer PDFRenderer(...)根据不同需求注入不同的渲染器。灵活度一下子高了很多新增格式也不用动主类逻辑。我的经验是代码复用不超过两层的时候继承很顺手一旦层级深了或者一个类会从多个维度变化优先考虑组合。这条建议值得你写进自己的编码规范里。3. 多态Python 的多态和 Java 不一样3.1 鸭子类型——Python 多态的真正实现方式在 Java 或 C 里多态通常意味着一个基类类型的引用指向子类对象调用同名方法时程序会根据对象的真实类型去执行对应版本的实现。这个机制建立在“显式的类型继承关系”上。Python 不一样。Python 的多态核心是鸭子类型duck typing——“如果它走起来像鸭子、叫起来像鸭子那它就是鸭子”。换句话说Python 不关心一个对象是否继承了某个特定基类它只关心这个对象有没有你要调用的那个方法。class Dog: def sound(self): return 汪 class Cat: def sound(self): return 喵 class Car: def sound(self): return 嘀嘀 def make_sound(obj): print(obj.sound()) make_sound(Dog()) # 汪 make_sound(Cat()) # 喵 make_sound(Car()) # 嘀嘀这三个类之间没有任何继承关系但它们都有sound()方法所以make_sound函数就能接受任何“会叫”的对象。这就是多态在 Python 里的朴素体现调用方只依赖对象的接口不依赖对象的类型。这对设计有什么影响呢它意味着 Python 里“多态”的约束是隐式的。好处是你写出来的代码非常灵活新增一个类只要方法名对得上老的调用方代码一行都不用改坏处是如果不小心等运行时才发现对象缺少了某个方法。所以 Python 社区里有很多“协议”的概念比如__iter__、__enter__、__len__。所谓“实现了某个协议”本质就是说“我有这个方法你可以放心调用”。这是鸭子类型在 Python 里最高频的应用场景。3.2 用抽象基类给多态“画条线”鸭子类型太自由了自由到有时候团队协作时容易失控。比如同事小张写了一个函数约定传入的对象要有read()方法但另一个同事传进来一个没有read()的对象结果代码运行到那个位置才崩溃大家排查了半天。如果你希望“结构上就保证传入的对象一定满足某个接口”标准库里的abc模块能帮你做到。抽象基类Abstract Base ClassABC允许你定义一组强制子类实现的方法凡是继承了抽象基类但没有实现全部抽象方法的类根本无法实例化。from abc import ABC, abstractmethod class Shape(ABC): abstractmethod def area(self): pass class Rectangle(Shape): def __init__(self, width, height): self.width width self.height height def area(self): return self.width * self.height # 尝试实例化一个没有实现 area 的类会直接报错 class Circle(Shape): pass c Circle() # TypeError: Cant instantiate abstract class Circle # with abstract method area这个机制不是要替代鸭子类型它是给“鸭子类型”增加了一道编译期更准确地说是实例化期的检查。适合用在那些接口约定非常稳定的场景比如框架内部定义插件接口或者团队里多人协作时明确“你实现的模块必须提供这些方法”。但也要提醒一句别把所有类都做成抽象基类那就陷入“过度设计”了。Python 的哲学是灵活优先不是所有场景都需要提前约束。我自己一般遵循这样的原则写库或框架、面向外部使用者时用抽象基类明确接口项目内部几个类之间的临时协作鸭子类型完全够用加抽象基类反而拖慢节奏。3.3 多态让代码消除 if-else 的实际案例多态最直接的价值体现在消除大量的if-else或elif分支。想象一个订单折扣系统不同的用户等级有不同的折扣规则def get_discount(user_type): if user_type normal: return 0.95 elif user_type vip: return 0.9 elif user_type svip: return 0.8 else: return 1.0这个函数用起来没问题。但每次新增一个用户等级你都要回来改这个函数——这是典型的“开闭原则”违反案例代码对扩展没有天然地“打开”。用多态重构一下class User: def get_discount(self): return 1.0 class NormalUser(User): def get_discount(self): return 0.95 class VIPUser(User): def get_discount(self): return 0.9 class SVIPUser(User): def get_discount(self): return 0.8调用方的代码变成了def apply_discount(user, price): return price * user.get_discount()新增一个用户等级时只需要新写一个User的子类不需要动apply_discount。这就是多态对代码结构最实质的改善把“针对不同类型做不同处理”的逻辑打散到各个类内部调用方保持稳定。我见过很多老项目里的巨型if-elif链动辄几十个分支。那种代码不是不能跑但是每次需求变动都要小心翼翼地在某个分支上修来修去测试面特别大。用多态重构之后每次改动收敛到一个类里风险和改动范围都大大缩小。这个经验是我在多态上收获最大的实际应用。4. 封装私有属性、保护属性与 property 的边界4.1 单下划线和双下划线的真实区别封装在 Python 里是一种“约定优先于强制”的机制它不像 Java 那样用private关键词把属性完全锁死。先记住这个总基调然后我们看两个下划线约定。单下划线开头_attribute表示“这是内部属性外部不应该直接访问”。它只是一个约定如果你非要在外部访问Python 不会拦你代码也能正常运行。它更多是写给人的提示看到_name你就知道这个属性不是公共接口的一部分最好不要碰。双下划线开头__attribute就稍微复杂一点了。它触发了 Python 的名称改写name mangling机制在类定义内部__attribute会被改写成_ClassName__attribute。这不是为了绝对的安全而是为了避免在继承场景下子类的同名属性与父类冲突。class Father: def __init__(self): self.__money 1000 class Son(Father): def __init__(self): super().__init__() self.__money 500 s Son() print(s.__dict__) # {_Father__money: 1000, _Son__money: 500}看到没父类和子类各自定义了一个__money但因为名称改写它们实际是_Father__money和_Son__money互不干扰。如果你用单下划线_money子类的赋值就会把父类的属性覆盖掉。有人在网上说“双下划线就是私有不能访问”其实不准确。如果你知道改写规则还是可以强行访问的比如s._Father__money。所以我的态度一直很明确双下划线的主要价值是规避继承冲突不是用来做严格保密。真正需要藏起来的信息应该放在安防设计里考虑而不是靠语言特性。4.2 property 的工作原理与常见用途property是 Python 封装的灵魂。它让你可以在不改变外部调用方式的情况下把“访问一个属性”变成“执行一段逻辑”。先看一段典型场景。假设有个用户类直接暴露属性age外部可以随便设成负数class User: def __init__(self, name, age): self.name name self.age age u User(小明, 18) u.age -5 # 没有报错但明显不合逻辑加上property之后你可以把age从“直接存取的属性”改成“由逻辑控制的属性”class User: def __init__(self, name, age): self.name name self._age age property def age(self): return self._age age.setter def age(self, value): if value 0: raise ValueError(age cannot be negative) self._age value现在当外部执行u.age -5时会走setter里的校验逻辑直接抛异常。而读取u.age则走getter。这个特性在项目里最常见的用途有几个一是校验就像上面这个例子。设置属性前检查值的合法性避免脏数据进入对象内部。二是计算属性。有些“属性”不是存储在实例里的而是由其他数据实时算出来的。比如一个订单类class Order: def __init__(self, price, quantity): self.price price self.quantity quantity property def total(self): return self.price * self.quantitytotal看起来是个属性外部调用是order.total不需要加括号但它其实是实时计算的。这样调用方写起来很自然不用区分“哪些是存的哪些是算的”。三是向后兼容。项目初期User类直接暴露了age属性很多代码都在用u.age。后来需求变了你希望在读取age时顺便做别的操作如果不希望改所有调用方的代码就可以把age改造成property外部代码一行都不用动只有内部逻辑升级了。这种“最小改动就能升级接口”的能力在维护老项目时价值巨大。4.3 不要过度封装什么时候该直接暴露属性有一类同学学了封装之后变得特别激进所有属性全都加下划线所有访问都写 setter/getter最后代码又臭又长。这其实走偏了。Python 的设计哲学里有一条叫“我们都要对自己的行为负责”。如果一个属性就是纯粹的存取不需要校验、不需要计算、不需要控制访问那就直接暴露它不要为了写 setter/getter 而写。# 过度封装 class Point: def __init__(self, x, y): self._x x self._y y property def x(self): return self._x x.setter def x(self, value): self._x value property def y(self): return self._y y.setter def y(self, value): self._y value这段代码没有任何问题但它也什么都没解决。字段就是两个坐标点不需要约束直接写self.x x、self.y y就是最清晰的代码。那什么时候值得封装三条标准赋值或读取时需要有额外逻辑比如校验、换算、记录日志。属性的值不是直接存储的而是由其他状态计算得到的。你预期未来可能加逻辑现在先用property给调用方一个稳定接口防止以后外部代码大面积改调用方式。我个人的习惯是一开始尽量保持属性公开等真的出现约束需求了再加property。Python 的蛇形命名和动态特性决定了从公开属性改成property的成本非常低外部调用代码几乎不用动所以没必要一开始就层层包裹。过早地加 getter/setter只会让代码读起来冗余还不利于新手理解。5. 实战拿“员工薪资系统”把三大特性串起来5.1 需求与类设计概念聊得再多不落地都是空中楼阁。我们来做一个小而完整的实战员工薪资系统。需求是这样的公司有普通员工、经理、实习生三种角色。普通员工拿固定月薪经理除了固定月薪还有项目奖金实习生按小时计费。我们需要一个统一的方法能够计算任意员工的总收入并且在展示信息时能区分不同角色。这个需求看起来简单但足够展示继承、多态、封装三个特性的配合。先看类设计基类Employee包含所有员工都有的公共信息姓名、工号以及一个待子类实现的计算薪资方法get_pay()。子类Manager继承Employee添加bonus属性重写get_pay()。子类Intern继承Employee添加hourly_rate和hours属性重写get_pay()。用一个统一的调用函数接受任意员工对象打印员工信息和薪资——这个函数不用关注具体是什么子类这就是多态。5.2 完整代码实现与逐段讲解先写基类。注意我用property把name和emp_id包了一层主要是演示封装的用法from abc import ABC, abstractmethod class Employee(ABC): def __init__(self, name, emp_id): self._name name self._emp_id emp_id property def name(self): return self._name property def emp_id(self): return self._emp_id abstractmethod def get_pay(self): 计算员工应发薪资子类必须实现 pass def show_info(self): return f员工{self.name}工号{self.emp_id}这里Employee继承自ABC并且get_pay加了abstractmethod装饰器这意味着不能直接实例化员工必须由子类实现get_pay才能实例化。这个设计很合理一个没有具体薪资计算规则的“通用员工”不应该能实例化。接着写子类class Manager(Employee): def __init__(self, name, emp_id, base_salary, bonus): super().__init__(name, emp_id) self.base_salary base_salary self.bonus bonus def get_pay(self): return self.base_salary self.bonus class Intern(Employee): def __init__(self, name, emp_id, hourly_rate, hours): super().__init__(name, emp_id) self.hourly_rate hourly_rate self.hours hours def get_pay(self): return self.hourly_rate * self.hoursManager和Intern都通过super().__init__(name, emp_id)把基类负责的初始化接力下去然后各自保存自己的新增字段并且各自实现了get_pay()。注意两个子类都没有定义show_info但它们都能调用show_info这就是继承对公共逻辑的复用。现在写一个统一处理员工信息的函数def print_pay(employee): print(employee.show_info()) print(f实发薪资{employee.get_pay()} 元) manager Manager(张经理, M001, 15000, 5000) intern Intern(小李, I001, 25, 80) for emp in [manager, intern]: print_pay(emp)这里就是多态发挥威力的时候。print_pay函数根本不需要知道传入的是Manager还是Intern只要这个对象有show_info()和get_pay()方法就能正常工作。以后新增一个岗位角色只要它是Employee的子类且实现了get_pay()这个函数无需任何修改。5.3 运行结果与设计复盘运行上面这段代码输出是员工张经理工号M001 实发薪资20000 元 员工小李工号I001 实发薪资2000 元现在复盘一下这个例子里的设计继承用在哪里Manager和Intern复用了Employee的name、emp_id、show_info。多态用在哪里print_pay统一调用get_pay()不同子类给出不同实现。封装用在哪里name和emp_id被包成property外部不能直接改保证了员工基本信息的安全。这个例子的最后我建议你做一个小练习新增一个Director角色薪资规则是年薪 股权折算成月收入。你试试只需要新增一个类、不改任何现有代码整个系统就能跑起来。做成了这个题你就真正理解了面向对象设计的意义——新的需求来了老的代码稳如泰山你只需要在文件的末尾追加一段新类。6. 常见问题与排查技巧实录6.1 五个高频报错和解决办法我在带项目时总结过一套“OOP 高频报错速查”这里整理给你。第一个是AttributeError: XXX object has no attribute yyy。这个报错十次有八次出在__init__里。要么是忘了调用super().__init__()父类初始化的属性没有设置要么是属性名拼写不一致比如self.name写成了self.nmae。排查办法很简单打印实例的__dict__属性看看这个对象里到底存了哪些键。print(obj.__dict__)第二个是TypeError: Cant instantiate abstract class XXX with abstract method yyy。说明你继承了一个抽象基类但没有实现里面的抽象方法。检查一下是不是漏了abstractmethod对应的方法或者方法名是否与父类一致。这里特别容易遇到的一个问题是Area()和area()大小写不一致Python 方法名是区分大小写的写错了就等于没实现。第三个是TypeError: super() takes at least 1 argument (0 given)。这个基本可以判定是 Python 2 的习惯混到 Python 3 里了。Python 3 的类内部直接写super()就行不用传参传入类名和实例反而是多此一举。检查一下文件头有没有from __future__ import ...之类的历史遗留代码。第四个是多重继承里__init__被调用了多次导致属性被重复设置或计算错误。这个问题的根源往往是某个中间类里没有正确调用super()把初始化链条打断了。解决办法是链路上的每个类都写super().__init__(...)保持 MRO 链条的完整。第五个是明明在子类里重写了方法调用时却还是走了父类的实现。这种情况先别怀疑 Python先看是不是方法名写错了再看__mro__的顺序最后看有没有在子类里因为拼写把方法写成了别的名字。对 Python 而言run和run_是两个完全不同的方法前者重写、后者是新增不会自动帮你建立“语义相同”的关联。6.2 三个典型的逻辑坑除了报错还有三个逻辑层面的坑代码不报错但行为完全不符合预期。第一个是可变默认参数。这个坑不止发生在类里但类方法里特别常见class ShoppingCart: def __init__(self, items[]): self.items items cart1 ShoppingCart() cart1.items.append(apple) cart2 ShoppingCart() print(cart2.items) # [apple]你没看错cart2的购物车里也出现了苹果。原因是默认参数items[]在函数定义时只会被创建一次所有实例共享同一个列表对象。正确写法是itemsNone然后在__init__里判断def __init__(self, itemsNone): self.items items if items is not None else []第二个坑是动态添加新属性导致property失效。比如你给了property的 getter但没有写 setter外部执行obj.age 20会报AttributeError: cant set attribute。如果你希望属性只读这是预期行为如果你希望可写记得写age.setter。我还见过更隐蔽的版本类里定义了property但实例化后某个地方直接给实例绑定了同名属性下次访问时命中实例属性property反而不生效了。遇到这种问题打印obj.__dict__就能一眼看穿。第三个坑是重写方法时忘了super()调用导致父类的关键逻辑被“悄悄绕过”。这很常见尤其是初学者重写__init__、save这类方法时写完子类的逻辑直接return把父类的关键初始化步骤跳过运行一段时间后才在某处爆出状态不一致。我的建议是子类重写方法时先想一想这个方法是“完全替换父类逻辑”还是“在父类逻辑基础上做扩展”后者必须在方法开头调用super().xxx()。这是 OOP 设计里一个极其重要的习惯。6.3 调试建议怎么一步步定位 OOP 问题最后分享一套我排查类相关问题时的固定套路。第一步先把对象“解剖”开看内部状态。不管报错还是不报错先打印obj.__dict__看看对象里实际存了哪些属性。这个操作能过滤掉一半的“属性不存在”和“属性值不对”类问题。第二步看类型和继承链。用type(obj)确认对象的实际类型用obj.__class__.__mro__查看方法查找顺序。我经常遇到的一种情况是对象看起来是SubClass实际却是另一个类因为在某处被重新赋值了。第三步缩小范围做最小复现。如果问题出在一个大类的复杂协作里我会写一个 10 行以内的最小脚本把相关的几个类抽出来单独测试。很多时候问题不是出在类本身而是出在类与类之间的协作顺序上。比如一个组件没有被正确注入一个依赖没有提前初始化这些都要靠最小复现脚本一步一步验证。这三个步骤说起来简单但投入回报率极高能帮你从“瞎猜”变成“按证据找问题”。我在任何项目里调试面向对象代码都是这个流程。