互操作性的力量：对象为何不可避免

导读

这是 Jonathan Aldrich 的一篇论证性随笔，试图解释为什么面向对象（尤其是对象所提供的互操作能力）是“不可避免”的：它把对象与抽象数据类型（ADT）相对比，认为对象支持动态分派、可替换的实现以及接口的渐进演化，因而更适合大型、长期演化的代码库中模块之间的组合与复用。作者的立场是，OO 的流行并非纯粹的时尚或炒作。

HN 关注点：HN 读者争论的焦点是：论文是否只是先假定现有 OO 语言的特性为理想，再反推 OO 最优；以及 OO 与 FP、ADT 的取舍究竟在哪里。

关键词　OOP抽象数据类型dynamic dispatch软件设计

HN 评论精选

这几条评论里：质疑 3　补充 1

质疑批评论文循环论证：先假定 OO 特性为理想，再推出 OO 最优。

作者论证了 OOP 所涵盖的那些功能，却没有解释为什么它们应该被归到同一个抽象之下——他只是默认如此，于是自然得出了“对象”这个答案。他对 FP 的一些看法也很奇怪：比如他指出 Haskell 的类型系统区分同构列表与异构列表，却把这当作缺点。我强烈感觉这篇论文是倒着论证的：先假定常见 OOP 语言的特性就是理想状态，再由此推导出 OOP 是最佳范式。

weavejester查看英文原文

The author makes arguments for the functionality that OOP encompasses, but doesn't attempt to explain why these should be grouped under one abstraction. Instead the author assumes that this should be the case, and rather naturally ends up with the answer of objects. The author also has some curious opinions about FP approaches. For example, he points out that Haskell's type system distinguishes between homogenous and heterogeneous lists, but then considers this to be a disadvantage. I get the strong impression that the paper is arguing backward; assuming that the properties of common OOP languages are the ideal, and then deriving from that assumption the answer that OOP is the best paradigm.

质疑指出论文对 ADT 定义过窄，并据实证称接口演化比实现替换更常见。

作者对比“对象”和“ADT”，但他对 ADT 的定义在我看来过于贫乏。我一直认为 Parnas 的《On the criteria to be used in decomposing systems into modules》才是 ADT 的关键论文——作者引用了它（文献[26]），却没有在这个论证里用上。他采用的区分是：对象可以有不同实现，而 ADT 不能，由此推出一连串“有多种实现”的好处。但据我浏览，他似乎没有提到接口的演化：实践中更常见的不是“同一接口换个实现”，而是新增内容——多些数据、多些服务、多些特性，通常做法是保持旧有部分不变以兼容老客户端，只新增方法或类型。我为了序列化（必须存储并重建对象）而对 Java 标准包中类的演化做过相当深入的研究，发现实践中实现变更而接口不变的情况其实相当少见，也就是说：接口演化比单纯的实现演化更常见。

hyp0查看英文原文

The author contrasts "objects" and "ADTs" (abstract data types), but uses - to my mind - an improvished definition of ADTs. I've always thought of On the criteria to be used in decomposingsystems into modules (Parnas) as the key paper for ADTs, which the author cites (at [26]) but doesn't use for this purpose. Of course, different definitions are available. The distinction the author uses is that objects can have different implementations, but ADTs can't. From this follows a streams of motherhoods of the advantages of having different implementations. Curiously, from my scan, he doesn't seem to mention evolution of interfaces. That is, instead of evolution being just a different implementation of an identical interface, it is much more common for something to be added: extra data, extra services, extra features. The typical approach is to leave everything the same (so that old clients still work with this new API), and strcitly only add new methods (and/or types with superset values). My reasonably involved studies of the evolution of Java classes in the standard packages for the purposes of serialization (which must store and recreate them), showed me that in practice, it's pretty rare for an implementation to change without the interface also changing. That is, I'm claiming: Interface evolution is more common than implementation evolution alone. To be clear: although implemenation evolution can and does occur (e.g. intern aspects of String recently), it's pretty rare to occur without the interface also changing. Not counting simple bug-fixes, which don't substantially change the implementation, and also not taking into account interfaces that were initially designed to have multiple implementation (e.g. collections, swing/awt, some networking classes etc), as these aren't evolution. (Though, I suppose adding a new implementation of existing interfaces e.g. LinkedHashMap (ordered map) counts as "evolution".) This higher frequency of interface evolution may be a reflection that we get paid for features, not refactoring.

补充论文只谈单分派，忽略了多分派在表达多主体交互上的优雅。

据我理解，这篇文章强调了动态分派的重要性，但隐含地只讨论单分派（即 OOP），完全没提多分派。单分派对于建模“单一主体”封装的过程很好甚至足够，但多分派在表达多个主体之间的交互时要优雅得多。例如 a.sum(b) 和 b.sum(a) 都不如 sum(a,b) 那样易于扩展。

ssivark查看英文原文

IIUC, this article highlights the importance of dynamic dispatch, but implicitly restricts itself to single dispatch (OOP) completely eliding any mention of multiple dispatch. Single dispatch is great/sufficient for modeling process encapsulated by a “single agent” but multiple dispatch feels far more elegant to encode interactions between multiple agents. Eg: Neither a.sum(b) nor b.sum(a) is as cleanly extensible as sum(a,b)

质疑OO 导致概念与类的增殖，设计模式是复杂度膨胀的典型。

对象的主要问题是概念实体的增殖：它增加而不是降低复杂度。设计模式的出现就是明证——它引入了大量本意是简化编程的概念，实际上却常常让类的数量指数级膨胀，理解力却没有提升。有时去掉这根拐杖代码反而更好，但 OO 语言的设计本身就在鼓励这种做法。

coliveira查看英文原文

The main problem with objects is the proliferation of conceptual entities that increase complexity instead of reducing it. This was in full display with the creation of design patterns, which introduced a large number of concepts meant to simplify programming, but that in fact multiplied the number of classes in an exponential way sometimes without improving understanding. Sometimes you'll have better code by just removing the crutch, but OO languages are designed to favor this kind of approach.

历次讨论

2014Hacker News 讨论帖51 分 · 43 评
2021Hacker News 讨论帖58 分 · 24 评
2024Hacker News 讨论帖39 分 · 23 评

HN 二十年，最值得读的论文。

朋友分享的书单

专题阅读路线

本周最多人读

我的书单

必读 30 篇

论文库

这些论文是怎么挑出来的

全量扫一遍

只留论文本身

写导读、译评论

互操作性的力量：对象为何不可避免

导读

HN 评论精选

相关资源

历次讨论

同领域还值得读

Google 的软件工程（2017）

Peter Naur：编程作为理论构建 (1985)

SciPy 1.0：Python 科学计算的基础算法

Lisp 的历史（1979）

使用 NumPy 进行数组编程

打赏支持

关注向阳乔木