不一定。Python面向对象编程的核心是类与对象组织代码、封装、继承和多态，建模现实世界并非强制要求；日常脚本、数据清洗、简单CLI等场景用函数更直接，而状态共享、行为复用、参数冗余时才建议建模；Python支持dataclass、模块、闭包等多元抽象方式，OOP是工具而非教条。
不一定。Python 面向对象编程（OOP）的核心是用类和对象组织代码、封装数据与行为、支持继承和多态，但“建模”——即严格对应现实世界实体并抽象出完整类结构——只是其中一种应用场景，并非强制要求。
什么时候可以不建模？
很多日常任务根本不需要映射现实概念：
- 写个脚本批量重命名文件，用函数+路径操作更直接，没必要设计
FileRenamer类 - 处理一次性的数据清洗逻辑，用纯函数配合
pandas就够了，硬套类反而增加冗余 - 简单命令行工具，参数解析+几行业务逻辑，类带来的初始化、实例管理反而拖慢开发节奏
什么时候建议建模？
当出现以下信号时，建模才真正带来好处：
- 状态需要被多个操作共享和维护（比如一个网络连接对象要保持 socket、超时、重试次数等）
- 同一类行为在不同数据上重复出现（如对用户、订单、商品都需“校验→保存→发通知”，适合抽象基类或策略模式）
- 代码开始频繁传递大量相关参数（
process(data, config, logger, cache, timeout)→ 考虑封装进Processor实例）
Python 的灵活性：类不是唯一抽象方式
Python 允许混合范式：
立即学习“Python免费学习笔记（深入）”；
- 用
namedtuple或dataclass快速表达轻量数据结构，不带复杂行为，也算 OOP 的简化建模 - 用模块组织相关函数（如
utils.date_helper），本质是命名空间级的封装，替代简单类 - 用闭包或工厂函数生成定制行为，比空有接口的类更简洁（例如返回不同验证规则的函数）
面向对象是工具，不是教条。Python 不强制你为每段逻辑造一个类，也不惩罚你用函数解决问题。关键是看它是否让代码更易理解、复用和演进——而不是有没有画出 UML 图。
