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_level，Python 会自动创建一个实例属性，只会影响该实例；如果你修改类的 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 f"Vector({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 的语法习惯。如果你能把这一整套串起来，在你的实际项目中挑选合适的地方用起来，那面向对象对你来说就不再是纸上概念了。
我在写这段内容的时候一直在想，学编程最怕的是记住了语法，却没有建立属于自己的设计直觉。好在设计能力是可以练出来的，最好的方式就是去读开源项目代码，看别人是怎么组织类和对象的。读的时候多问一句：这里为什么不写成一个函数？为什么要把某些方法放在同一个类里？这样读着读着，自己的设计直觉就会慢慢长出来。
