弃用观察者模式

导读

这篇论文指出传统观察者模式（尤其在 UI 事件处理中）存在诸多缺陷，提出用函数式响应式编程（FRP）中的“信号/事件流”作为一等公民来替代回调式观察者，并在 Scala 中以 Scala.React 库实现。作者认为统一的、类型安全的事件抽象能让事件逻辑更易组合和推理。

HN 关注点：HN 读者既对 Scala 与函数式编程有天然兴趣，也长期争论 Rx/FRP 究竟是消除复杂度还是把复杂度藏进抽象层。

关键词　Scala函数式响应式编程observer patternRx

HN 评论精选

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

质疑RX 只是把复杂度搬进更隐蔽的抽象层，并不能真正降低复杂度

以我的经验，响应式范式很少真正解决它宣称要解决的问题。根源在于论文这句话：“简化事件逻辑的第一步是提出一个通用事件接口，让所有事件处理代码都基于统一接口工作。”RX 支持者似乎认定：把逻辑包进一个高度通用的抽象层、把所有行为同质化为事件流，就能解决软件复杂度——我不清楚这个假设从何而来。看看 ReactiveX 的 API 就知道：它号称通用工具，实际却是一堆 observable 子类型和操作符的大杂烩，专门用来补“通用方案”在真实问题复杂度上留下的窟窿；再看看任何非平凡 RX 项目里那蜿蜒曲折的调用栈。我写得越多越相信，最佳实践是尽可能在最低抽象层、贴近问题域写代码。RX 这类想靠通用抽象“魔法般”降低复杂度的范式，最好的情况是把复杂度挪到另一层、变得更晦涩，最坏的情况是凭空增加复杂度。

skohan查看英文原文

In my experience the Reactive paradigm rarely serves to solve any of the problems it sets out to, and the root of the problem is here: > The first step to simplify event logic in an application is to come up with a general event interface so that all event handling code can work with a uniform interface. RX proponents seem to make the leap that the problems of software complexity can be solved by wrapping your logic into a highly general abstraction layer which homogenizes everything your code does into streams of events. I'm not entirely sure what this assumption is based on. To look at how this assumption breaks down, just look at the ReactiveX API: what's billed as a general purpose tool consists of a menagerie of observable subtypes and operators built to patch the holes in real-world problem complexity left by the "general case" solution described by this article. Or look at the serpintine call stack in any real-world RX project of any non-trivial complexity. The more I code, the more convinced I am that the best practice is to write software at the lowest level of abstraction possible, as close to your problem domain as possible. Paradigms like RX which seek to magically reduce complexity through generic abstraction at best move that complexity into another layer where it's more obfuscated, and at worst introduce additional complexity.

质疑热/冷、线程调度、取消等实际语义问题让 RX 在真实项目中难以驾驭

RX 纸面上很好看，但在任何非平凡项目里都是噩梦。这个流是热还是冷？每次订阅都会发请求，还是最多发一次？这个流在哪个线程投递？UI 线程吗？那就保险起见 dispatch 到 UI 线程吧！结果另一个流早了一个周期产生事件，UI 开始闪烁……那就在这儿加 1 毫秒延迟，祈祷它能修好（恶心）。还有，我该怎么取消这些东西？

aaaaaaaaaab查看英文原文

RX looks good on paper, but boy, is it a nightmare in any non-trivial project. Is this stream hot or cold? Will it fire the request every time I subscribe, or at most once? On which thread is this stream delivered on? UI thread? Let’s be safe and dispatch it to the UI thread! Oh, now my UI flickers because this other stream is producing this event one cycle too early... Let’s add one millisec delay here and hope it fixes the issue (yuck.). How do I cancel this stuff?

质疑追问论文是否超越了“换成类型安全回调”这一表层建议

我对文章的细节理解不深，能否有人回答：除了“改用信号”（我粗略定义为“类型安全的泛型回调抽象”）之外，文章还有没有更根本的主张？如果有，是什么？

roel_v查看英文原文

I don't quite understand the finer points of the article, so can somebody answer: is there a more fundamental suggestion in it than 'switch to signals' (which I for this purpose roughly define as 'type-safe generic callback abstractions')? If so, what is it?

补充FRP 适合游戏编程，但 Scala 缺乏活跃的成熟实现

响应式编程看起来非常适合游戏编程（我知道 Haskell 用 Yampa 做这个）。让我意外的是，Scala 竟然没有一个容易获取的经典实现。我在网上搜过，有几个框架，但都不太活跃。

michaels0620查看英文原文

Reactive programming seems like an excellent model for game programming (I know Haskell uses Yampa for this). I am surprised there isn't a canonical Scala implementation that is easily available. From my searching on the web, it looks like there are a couple of frameworks, none of which are particularly active.

历次讨论

2011Hacker News 讨论帖77 分 · 19 评
2018Hacker News 讨论帖77 分 · 26 评

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

朋友分享的书单

专题阅读路线

本周最多人读

我的书单

必读 30 篇

论文库

这些论文是怎么挑出来的

全量扫一遍

只留论文本身

写导读、译评论

导读

HN 评论精选

历次讨论

同领域还值得读

Google 的软件工程（2017）

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

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

Lisp 的历史（1979）

使用 NumPy 进行数组编程

打赏支持

关注向阳乔木