原文

What is the significance of late binding?

译文

(由 ChatGPT 翻译, 种瓜校对和微调)

“后期绑定” 是一种关于在保持尽可能多的灵活性和安全性的同时获得所需功能的想法。

一个需要考虑的重要因素是, “软件” 本身是计算机行为的后期绑定。（看起来是一个相当不错的想法, 我想说…）

在下一个层次上, 硬件中的索引寄存器的想法以一种不破坏代码的方式后期绑定地址。内存管理单元(MMU)允许封装的本地寻址进行全局重定位。各种类型的间接寻址允许在运行时更容易地进行更改。

考虑一个变量…

考虑子例程与内联代码的对比…

解释器延迟绑定计算机的语义。

将微码(microcode)视为通过解释器后绑定硬件的一种方式

封装的对象延迟绑定"怎么做(hows)"（方法）, 并允许仅通过 “什么(whats)"(意义)来使用, 这允许更容易实现各种替代方案和透明度。

“怎么做(hows)“本身也可以延迟绑定, 例如在 Lisp 或 Smalltalk 中, 这允许程序去分析系统的其他部分是如何设置的: 对"反射"进行分析, 以及事物是如何完成的。

“反射” 做得好, 允许更多务实的可能性, 即使在非常低的级别上也能安全高效地进行。一本好书是 Kiscales、Bobrow、Rivera 的《元对象协议的艺术》。

从战略的角度来看, 尽可能保留多的后期绑定是一个非常好的主意。如果确实需要的话, 动态地去除一些自由度是容易的, 但从早期绑定系统转向更灵活的方式则非常困难。

例如, 相当多的优化是违反模块边界并希望逃脱惩罚。以更有原则的方式做到这一点的一种方法是真正将后期绑定模块作为一个模型, 然后将违规行为实现为编程系统的"务实特性”。

例如, 在面向对象编程系统中, 一个方法可能有一个"左侧”, 仅仅是语义, 以及一个可选的带有优化情况的"右侧”。该方法应该在关闭右侧的情况下完美运行, 但在打开右侧的情况下会运行得更快等等。 (译者注: Smalltalk 的 primitive)

同样, 模块之间的交互也可以以这种双重方式处理。（例如, Smalltalk 是一个"消息传递系统", 但除非绝对需要, 否则不会表现出实际的消息。此外, Smalltalk 具有其所有语义的模拟, 并且如果某些机器的低级别不完整或存在错误, 则可以退回到它们。）

值得注意的是，优雅和有用的后期绑定的深层敌人是有害的(尤其是不必要的)依赖关系。这种情况可能发生在早期绑定系统中，但在后期绑定系统中有更多的可能性（因此需要更多的设计来真正利用这个想法, 这将在许多方面得到回报…）。

补充

补充我在其他地方看到的 Alan Kay 对后期绑定的看法:

如果你正在使用大多数人使用的前期绑定语言, 而不是后期绑定语言, 那么你一开始就被锁定在你已经完成的东西上。 – c2:Alan Kay Quotes

对我来说, OOP 只意味着消息传递、本地保留和保护以及隐藏状态-过程, 并且对所有事物进行极端的后期绑定。这可以在 Smalltalk 和 LISP 中完成。可能还有其他系统也可以实现这一点, 但我不知道 – Alan Kay(wikipedia)

参考