1. 从函数到类什么时候该用面向对象什么时候不该用很多 Python 初学者学到面向对象这一章时会有一个很真实的困惑我明明用函数也能把程序写出来为什么非得搞一个类出来我当年也有这个疑问而且坦白说在写一些几十行的小工具脚本时函数确实完全够用。但一旦代码量到了几百行、上千行或者你开始做跨文件的项目函数的写法就会出现一个很明显的问题——数据散落在各个函数之间彼此之间靠参数传来传去逻辑一复杂改一个地方就可能牵动一片。我在实际项目里见过最典型的例子是一个爬虫脚本。有人用纯函数写了一个抓取页面、解析数据、保存结果的三件套刚开始很顺利。但随着需求变化他需要增加请求重试、数据清洗、结果去重就发现这些功能之间需要共享一堆状态比如当前重试次数、已抓取的 URL 集合、解析失败的目标列表。这些状态如果都放在全局变量里很快就会乱成一锅粥。你无法确定哪个函数在什么时候改了这些变量排查问题时只能从头读代码。面向对象解决的核心问题是把数据和操作这些数据的方法绑定在同一个地方。对象是一组数据和操作的打包体它内部维护自己的状态外部通过方法来请求或改变这些状态。这种组织方式在代码规模变大之后会让你的程序结构清晰得多——你不需要追着变量去找它的生命周期因为变量的生命周期就在对象里。这也是为什么很多招聘要求里会写扎实掌握面向对象它考核的不是你背了多少概念而是你有没有能力组织起规模较大的代码。但我也要说一句得罪人的实话不是所有 Python 代码都要面向对象。如果你只是写一个一次性脚本、一个数据清洗的临时函数、一个简单的自动化任务用函数式或面向过程的方式反而更直接。Python 本身是多范式的语言它支持函数式、面向对象和面向过程。选择哪一种取决于你的代码复杂度。面向对象应当是你工具箱里的一个锤子而不是所有问题都往上砸。那什么时候该上类我自己的经验标准很朴素当你发现代码中有多个操作都在处理同一组数据并且这组数据需要被多个函数反复传递时就应该考虑用类把它们收拢。另一个信号是当你发现某些函数之间的耦合太紧修改一个往往要连带改另外几个时类可以把这种耦合关系显式地表达在内部结构里而不是散落在函数调用之间。2. 类与实例从第一个类开始理解init和 self理解了为什么需要类之后咱们直接上手写代码。定义一个类用的是 class 关键字这没什么好说的。真正让新手困惑的是类里面的init方法和 self 参数。先说init。它的名字看起来像是初始化的缩写也确实承担了初始化的职责。当你把类当模板创建实例时init会自动执行用来给这个实例设置初始状态。你可以把它理解成一张出生登记表一个新实例诞生时系统会问你这个实例叫什么名字、有哪些初始属性你告诉它于是它带着这些属性开始了自己的生命周期。class Student: def __init__(self, name, score): self.name name self.score score def show(self): print(f{self.name} 的分数是 {self.score})这里的 self 可能是新手最懵的东西。为什么每一个方法都要写 self为什么要放在第一个参数的位置因为 Python 在调用实例方法时会把调用这个方法的实例本身作为第一个参数传进来。比如 s Student(张三, 95)接着调用 s.show()Python 在背后做的事是 Student.show(s)把 s 传给了 self 参数。所以 self 指向的就是当前这个实例本身。这个设计对初学者来说有点绕但它的好处是显式。你自己看到 self.name name就非常清楚我要把传入的 name 值存在当前实例的 name 属性上。接下来有个很容易踩的坑你可能会在init之外定义一些看起来像是初始化的代码发现执行顺序不对。记住一条原则——init是创建的固定流程它在该实例创建时执行一次。不要在init里做耗时太长的操作比如发网络请求、读大文件。如果实例化时就要加载大量数据我建议把加载逻辑拆成单独的方法一个常见的做法是写一个 classmethod用于从文件或接口创建实例。classmethod def from_file(cls, path): # 从文件读数据然后构造并返回一个实例 data open(path).read() return cls(data)这样调用 Student.from_file(score.txt) 就能得到一个实例而且这个方法的意图比把一大堆 IO 逻辑堆在init里要清晰得多。我在项目中就多次采用这种工厂式构造方法让初始化代码变得非常干净。再说一个新手常犯的错方法内部的局部变量和实例属性混淆。有些人会写class Student: def set_score(self, score): score score # 错的这只是一个局部变量没有赋值到实例正确写法是 self.score score。没有 self 前缀的变量就是方法里的局部变量函数调用结束它就消失了不会对实例产生任何影响。如果读者你以前犯过这个错现在纠正过来就好。3. 公开属性、私有属性与 property 装饰器Python 的封装哲学封装通俗说就是把属性藏起来不让外部直接随便改。但 Python 和其他语言不太一样它没有真正的强制私有机制。C 或者 Java 可以用 private 关键字强制保护变量外部代码访问就报编译错误。Python 的做法更像是一种约定——用双下划线前缀来给属性改名比如 _Student__secret外部代码很难直接猜到和访问。但这不是绝对的你仍然可以通过编译后的名字去触碰它所以它的作用是提醒不是阻止。class BankAccount: def __init__(self, balance): self.__balance balance def deposit(self, amount): if amount 0: self.__balance amount def get_balance(self): return self.__balance上面这个例子里__balance 被名称修饰机制改成了 _BankAccount__balance。你从外部直接用 account.__balance 会报错但用 account._BankAccount__balance 依然能取到值。这一点你要心里有数Python 的私有是一扇君子协定的门阻挡的是误操作不是故意的恶意。比私有属性更常用的是 property 装饰器。它让你可以在外部看起来是在直接操作属性实际上内部可以加校验逻辑。比如class Temperature: def __init__(self, celsius): self._celsius celsius property def celsius(self): return self._celsius celsius.setter def celsius(self, value): if value -273.15: raise ValueError(温度不能低于绝对零度) self._celsius value这样外部代码可以写 temp.celsius 25看起来只是改了一个属性实际上 setter 里的校验会被触发。我个人的经验是当需要维护一个对象的属性一致性时property 是一个非常优雅的工具它把赋值时的逻辑收敛在一个地方避免你在多个地方写同样的 if 校验。封装还有一个常被忽略的维度把内部状态机封装起来避免外部代码破坏对象的不变量。举个例子假设你写了一个播放器类它有开、关两个状态。如果直接把 self.is_on 暴露给外部调用者就可能写出 player.is_on True 而完全绕过你的状态切换方法。更好的设计是提供一个 start() 和 stop() 方法内部的 is_on 属性设为私有外部只能通过方法来改变。这样可以保证状态切换时伴随的其他逻辑比如设置音量、挂载资源一定会执行。我在编写类的过程中有一个实际体验刚开始很爱写一堆 getter/setter后来发现没必要直接暴露公开属性反而更简洁。property 应该用在真正有校验需求或计算型属性的场合而不是所有属性都套一层。别为了封装而封装简洁和可用性也是设计目标的一部分。4. 继承与多态其实 Python 玩的是鸭子类型继承是面向对象的重头戏。它的作用是让你在已有的类基础上扩展新类复用基类的属性和方法。比如你有一个 Animal 类里面定义了 speak 方法那么 Dog 和 Cat 类都可以继承 Animal直接复用 speak并在需要的时候重写它。class Animal: def speak(self): return class Dog(Animal): def speak(self): return 汪汪 class Cat(Animal): def speak(self): return 喵喵这里涉及一个概念叫重写也就是子类定义了与父类同名的方法调用时优先用子类的实现。多态就体现在这你有一个函数接收一个 Animal 类型的对象然后调用它的 speak 方法不用管它到底是 Dog 还是 Cat只要它实现了 speak 方法就行了。不过 Python 的多态和 Java、C 不太一样。Python 不要求在编译时检查类型它只看对象到底有没有这个方法。只要你传入的对象实现了 speak 方法程序就能运行。这就是鸭子类型走起来像鸭子、叫起来像鸭子那它就是鸭子。鸭子类型给 Python 带来很大灵活性但它也是一把双刃剑。因为不需要显式声明接口调用一个对象的方法前你往往要靠文档或直觉来确认方法存在。为了让代码更健壮我会在关键函数里用 hasattr 做一次检查或者配合抽象基类来约束子类必须实现某几个方法。说一个真实的教训我在某个微服务项目里客户端的配置类分别从两个不同的基类继承一个支持 JSON 序列化一个支持 YAML 序列化。我写了一个统一序列化函数在没仔细检查的情况下直接调了 to_yaml 方法结果某个配置类没有这个方法直到运行时才炸出 AttributeError。从那以后我明白了鸭子类型给了你自由你也要为自由负责。关于继承还有一个经常被误用的问题深继承链。我见过有人为了复用几个方法硬是构造了五层继承。结果代码变得极其难读你找某个方法的具体实现要一层一层往上翻。现在我更推荐组合优先于继承。也就是说如果你只是想复用某个类的部分功能不如把那个类的实例当作一个组件放在新类里直接调用它的方法。class Engine: def start(self): pass class Car: def __init__(self): self.engine Engine() def start(self): self.engine.start()组合让类之间的关系更松散改起来更灵活。继承更像是是一个的关系组合更像是有一个的关系。实际开发中有一个的场景远多于是一个。5. 几个容易忽略的语法细节类属性、实例属性、类方法、静态方法面向对象初学阶段常把属性和方法混在一起讨论但它们的作用域和归属其实差别很大。类属性是写在 class 内部、方法外部的变量它属于类本身所有实例共享同一份数据。实例属性是写在init里的 self.xxx它属于具体实例每个实例有自己的一份。class Player: max_level 100 # 类属性 def __init__(self, level): self.level level # 实例属性如果你修改实例的 max_levelPython 会自动创建一个实例属性只会影响该实例如果你修改类的 max_level所有实例共享的值都会变。这个区别常常导致难以排查的 bug。我在一个游戏后台项目里就见过运营后台把 Player.max_level 改了结果所有新创建角色都能升到更高的等级而老玩家那里却没受影响因为他们的线上实例在创建时已经把旧值复制成了实例属性。类方法和静态方法的区别也是高频考点。类方法用 classmethod 装饰第一个参数是 cls代表类本身。静态方法用 staticmethod 装饰第一个参数什么都不传就像普通函数一样。什么时候用哪个如果你在方法里需要访问类级别的属性或需要创建类的实例就使用类方法。如果方法和类的内容完全无关只是逻辑上放在这个类内部比较合适就用静态方法。class MathUtil: staticmethod def add(a, b): return a b class Database: classmethod def connect(cls, url): return cls(url)我在项目的实践是工具类里放一批静态方法保持它们纯净、无状态方便测试。而某些需要根据环境配置来创建实例的场景就使用类方法。这两种方法在接口层、框架开发里尤其常见。6. 特殊方法让对象用起来像原生类型Python 类有很多以双下划线开头和结尾的方法统称为特殊方法也有人叫魔术方法。它们的作用是让自定义对象融入 Python 的语法生态——比如你想让两个对象相加、打印对象、判断相等只需要定义相应的特殊方法。最基础的是repr和str。str负责面向用户的输出repr负责面向开发者的调试输出。比如你直接在交互环境里看到对象时用的就是repr而 print(obj) 用的是str。class Vector: def __init__(self, x, y): self.x x self.y y def __add__(self, other): return Vector(self.x other.x, self.y other.y) def __repr__(self): return fVector({self.x}, {self.y})定义add之后两个 Vector 对象就可以直接用加号相加。这种设计让代码写起来很自然读起来更像是在用原生的数字类型而不是在调用一堆方法。我强烈建议你在开发业务类时至少把repr写出来。它的好处是调试点上你能在日志里直接看到对象内容而不是看到一串object object at 0x7f...的无意义输出。这一个小习惯能大幅节省排查问题的时间。除此之外eq常用于定义对象相等逻辑len可以让对象支持 len()iter可以让对象变成一个可迭代对象。如果你正在写一个容器类那后面两个几乎是标配。特殊方法有一个共同特征它们是 Python 解释器在特定时机自动调用的。你不太需要手动传参数给它们。写add时加号左边对象触发add右边对象作为参数传入。如果右边对象类型不对你可以在方法开头做 isinstance 检查抛出 NotImplemented让 Python 转而尝试右边的反向方法。7. 站在实战角度如何设计一个合格的类理论讲完咱们用实际项目来整合一遍。设想我们要写一个图书借阅系统里的图书类。需求如下图书有书名、作者、ISBN、当前状态可借/已借出能够借出、归还、展示信息。此外要限制 ISBN 的合法性。我建议从需求中寻找名词和动词。名词通常是属性动词通常是方法。书名、作者、ISBN、状态都是名词借出、归还、展示都是动词。确认了这些类的轮廓基本就出来了。class Book: def __init__(self, title, author, isbn): self.title title self.author author self.isbn isbn self.is_borrowed False property def isbn(self): return self._isbn isbn.setter def isbn(self, value): # 简单校验长度 13 且只包含数字和连字符 if not isinstance(value, str) or len(value) ! 13: raise ValueError(ISBN 格式不正确) self._isbn value def borrow(self): if self.is_borrowed: raise RuntimeError(图书已被借出) self.is_borrowed True def return_book(self): self.is_borrowed False def __repr__(self): return f《{self.title}》 ISBN:{self.isbn} 状态:{在馆 if not self.is_borrowed else 已借出}我特意在 isbn 上加了 property 校验。如果你直接把 isbn 当公开属性用实例化之后很容易出现 book.isbn 123 这样随意的赋值数据规范就崩了。加了校验后从源头上避免脏数据进入对象。这个类的设计有几个要点第一方法只做一件事。borrow 只处理借出逻辑return_book 只处理归还。第二状态变化都通过方法来执行外部不能直接设置 self.is_borrowed。第三repr 足够清晰。在实际项目中类似 Book 这类业务对象还会涉及持久化需求。我通常会在类里加一个 to_dict 方法把对象转成字典方便写入数据库或返回给前端再用一个 classmethod from_dict 从字典构造对象。这其实就是前面讲过的工厂模式让对象在序列化和反序列化的边界保持整洁。8. 一个真实的经验分享设计类时的几个自我提问关于面向对象我们最后聊一点代码之外的东西。我在实际工作中每次设计新类之前都会问自己几个问题。第一问这个类真的需要存在吗有时候一个函数加一个字典就能搞定的事情非要用类来实现反而多了一层包装。类的存在应该带来信息聚合和方法归属上的好处而不是为了展示你会写 class。第二问类的职责是什么我见过很多类写着写着就变成了上帝类数据库、日志、业务逻辑、工具函数全往里面塞。遇到这种趋势我就会拆类。一个类只处理一件事改起来、测起来都轻松得多。第三问外部使用这个类的入口有哪些它们是否足够清晰如果外部要调用这类的功能需要先读五分钟源码才能搞懂怎么用那这个设计就是失败的。好的类设计应该是一看到方法列表就能直觉判断怎么用。第四问这个类容易测试吗如果一个类需要连数据库才能测那你在开发时一定会尽量绕开它测试覆盖率就会下降。尽量把纯逻辑和外部依赖分开让核心逻辑可以在不依赖外界的条件下被测试。你现在再回头看标题Python 面向对象的基本概念会发现它其实不是几个术语的堆砌。类是一个模板实例是模板产生的实体封装保护了对象内部状态继承和组合让我们在已有基础上扩展多态和鸭子类型让代码变得灵活特殊方法让对象更融入 Python 的语法习惯。如果你能把这一整套串起来在你的实际项目中挑选合适的地方用起来那面向对象对你来说就不再是纸上概念了。我在写这段内容的时候一直在想学编程最怕的是记住了语法却没有建立属于自己的设计直觉。好在设计能力是可以练出来的最好的方式就是去读开源项目代码看别人是怎么组织类和对象的。读的时候多问一句这里为什么不写成一个函数为什么要把某些方法放在同一个类里这样读着读着自己的设计直觉就会慢慢长出来。