为什么 OOP 存在：代码即现实
Why OOP Exists
回想大学时和 Tito 合作编写图书馆管理系统，我们卡在如何表示一本 book 上。Tito 负责封装 book 的底层实现，我只需调用他提供的函数来编写搜索逻辑。这让我意识到，代码的核心在于处理现实世界的事物。OOP 的本质就是为这些实体创建高层抽象，隐藏实现细节。无论是用奇怪的 Unicode 码点存储 book，还是用元组表示 author，只要接口一致，上层逻辑就能独立运行。Python 的 class 关键字正是为此而生，它为相关函数提供了天然的 namespace，让代码结构更清晰。OOP 并非复杂的语法糖，而是让程序员能像思考现实世界一样思考代码的思维方式。
代码是关于现实世界事物的，我们编写图书馆管理系统，就需要能够思考书籍、作者以及其他相关实体。
HN 评论区
63- reaanb2
这篇文章描述的那种 OOP 思路，最终会导致对象关系映射（ORM）、样板代码、数据库模式在代码中重复、导航式数据访问以及阻抗不匹配问题。它把 OOP 的定义局限于数据建模和分类学，而非围绕职责展开。像“告诉，别问”（Tell, don't ask）和“单一职责”这样的原则直接被无视了。在图书馆管理系统中，一本书有什么职责？它没有，它只是被记录的事实主体。更好的做法是识别解决方案空间中的行为组件，将它们构建为类/对象，让事实被封装在对象内部或在对象间传递。
- mickeyp
OOP 没问题。如果你的架构或设计需要，不用 OOP 也没问题。
人们往往忘了——就像《四人帮》那本设计模式书里讲的那样——语言和框架是不断演进的。
装饰器模式在 90 年代是一个小众但有用的抽象。而在今天的 Python 里，你只需 @decorate 就能搞定。这就是演进。
OOP 也是如此。封装以及与封装槽位（slots）共置的方法，相比基础结构体（structs）是一次极其强大的升级。如今大多数语言都支持一等函数和词法作用域，你可以用这种方式构建自己的封装。
这一切都没问题。选最适合的就行。
- mrkeen
admittedly 我读得挺快，但这其实就是结构体（structs）。
这里建模的所谓“行为”不过是数据访问。写 .name() 而不是 .name。
你完全可以自己写一个完整的构造函数来省去手动打包这些结构体的时间。而文章却把这称为“自动”。
（甚至在 C99 里你都不需要为结构体手写构造函数。其他现代语言应该也一样。）
- eru
- tarix29
这篇文章里没有任何内容是 OOP 特有的。用结构体和静态分发也能实现所有这些。在像 Go 或 Zig 这样支持点号语法的语言中，代码看起来也会非常相似。