早期绑定与后期绑定：相对优势和劣势是什么？
在讨论计算机语言的演变时，Alan Kay 说他的 Smalltalk 的最重要的一个属性是后期绑定； 它赋予语言可塑性和可扩展性，并允许随着时间的推移重构不适当的耦合。 你同意？ 早期绑定是否存在补偿优势，可以解释为什么它似乎是可以使用其中任何一个的领域的两种范式的主导？
我的个人经验（不够广泛或不够深入，不足以具有权威性），基于使用 javascript、jQuery、jsext、actionscript、php、java、RoR 和 asp.net 实现 Web 应用程序，似乎表明后期绑定和膨胀之间存在正相关关系减少。 我确信早期绑定有助于检测和防止一些类型安全错误，但自动完成和良好的 IDE 以及一般良好的编程实践也能起到同样的作用。 因此，在我的风险规避方面恢复我的理性观点之前，我倾向于发现自己支持后期约束方面。
但我真的不知道如何平衡权衡。
When discussing the evolution of computer languages, Alan Kay says that the single most important attribute of his Smalltalk is late binding; it gives the language its malleability and extensibility, and allows inappropriate coupling to be refactored out over time. Do you agree? Are there compensating advantages for early binding that explain why it seems to be the dominant of the two paradigms for domains where either could be used?
My personal experience (which is not broad or deep enough to be authoritative), based on implement web applications with javascript, jQuery, jsext, actionscript, php, java, RoR and asp.net seems to suggest a positive correlation between late binding and bloat reduction. Early binding I'm sure helps detect and prevent some typesafety errors, but so do autocompletion and a good IDE, and good programming practices in general. So I tend to catch myself rooting for the late binding side, before my risk-avoidance side restores my rational perspective.
But I really don't have a good sense for how to balance the tradeoffs.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
根据我对高性能软件（例如游戏、数字运算）和性能中立软件（网站、大多数其他软件）的经验，后期绑定有一个巨大优势：可延展性/可维护性/你提到的可扩展性。
早期绑定有两个主要好处。 第一个：
被普遍接受，但通常无关紧要，因为在大多数情况下，可以通过硬件来解决问题，而且成本更便宜。 当然，也有例外（例如，如果您不拥有正在运行的硬件）。
早期绑定的第二个好处：
似乎被低估了。 在开发人员使用其他人的组件的大型项目中，IDE 可以读取早期绑定并使用它们来通知开发人员（通过自动完成、文档等）。 这对于后期绑定不太实用，因为绑定是在运行时创建的。 如果 IDE 可以从代码推断结构定义，那么使用后期绑定语言仍然是可能的，但由于结构总是可以在运行时更改，因此它不太可靠。
易于开发是一件大事。 它可以最大限度地减少程序员昂贵的时间——而且您的开发团队越大，它就变得越重要。 您需要平衡这一点与后期绑定语言所获得的灵活性。
In my experience of both high-performance software (e.g. games, number-crunching) and performance-neutral software (websites, most everything else), there's been one huge advantage of late binding: the malleability/maintainability/extensibility you've mentioned.
There've been two main benefits of early binding. The first:
is commonly accepted, but generally irrelevant because in most cases it's feasible to throw hardware at the problem, which is cheaper. There are, of course, exceptions (e.g. if you don't own the hardware you're running on).
The second benefit of early binding:
seems to be underrated. In large projects where developers are working with other people's components, IDEs can read the early bindings and use them to inform the developer (with autocompletion, docs, etc). This is less practical with late-binding because the bindings are created at runtime. It is still possible with late-binding languages if the IDE can infer structure definitions from the code, but since the structure can always be changed at runtime, it's not so reliable.
Ease of development is a big deal. It minimizes expensive programmer time -- and the larger your development team, the more significant it becomes. You'd need to balance that against the flexibility you get with late-binding languages.
传统上，早期绑定的一大优势是性能：后期绑定语言必须在运行时携带有关其所有数据的类型信息，并且失去了在编译时进行一些优化的机会。 然而，随着计算机变得更快，并且虚拟机在动态优化方面变得更加智能，这种差异已经变得不那么重要了。
Traditionally the big advantage of early binding is for performance: a late binding language has to carry type information about all its data at runtime, and loses the opportunity to do some optimizations at compile time. This difference has become much less significant, though, as computers get faster, and as VMs get smarter about optimizing on the fly.
晚吃东西可以让跑步系统自我扩展。 例如，系统启动时了解狼。 随着时间的推移，在 Wolf(?) 中，evolutionDometicate() 方法会旋转一个名为 Dog 的新类并实例化它，现在我们有了 Dogs。 Smalltalk 会保存整个系统映像，因此如果您关闭并重新启动，Dogs 在重新启动后仍然存在。 一旦演化为在特定硬件上运行并连接在网状网络中的对象，整个生态系统就不会真正关闭（直到 Sun 崩溃）。 我想这就是艾伦·凯所说的后期绑定的优势，成为上帝。
Late-binging allows the running system to extend itself. For example, system starts up knowing about Wolves. As time passes an evolveDomesticate() method, in Wolf(?), spins a new class called Dog and instantiates that and we have Dogs now. Smalltalk would save the whole SYSTEM image so if you shut it down and restarted, Dogs would still exist after restart. Once you evolve to objects running on particular hardware and connected in a mesh network there is no real shutdown of the whole ecosystem (not until Sun blows up). I think this is what Alan Kay was talking of the advantage of late-binding, become a God.
早期绑定与后期绑定实际上是语言架构的一个功能。 早期绑定意味着可以在机器指令跳转到某个地址并从那里开始执行的地方构建代码（可能通过查找表）。 后期绑定需要为每次访问查找符号和类型引用（通常是哈希表查找），这会减慢语言速度。
而一些基于 VM 的语言（例如 Java）是早期绑定的，本机代码只能真正直接进行早期绑定。 要进行后期绑定，它必须执行与动态语言解释器相同类型的哈希查找。 然后，后期绑定需要执行一段代码来获取地址（这就是 OLE 自动化的工作原理）。 它不能直接由 CPU 完成——必须执行代码。
请注意，执行后期绑定的代码实际上在哈希查找函数等中具有其自己的早期绑定分支目标。 因此，从这个角度来看，对于任何要由CPU直接执行的代码来说，早期绑定都是必要的。 后期绑定必须在软件中完成。
对于各种各样的代码优化来说，早期绑定也是必要的。
可以说，C 等架构在编写接近金属的代码方面具有最佳优势。 如果您想要这样做，早期绑定方面几乎是语言架构所固有的。 在诸如 Python 之类的后期绑定语言中，后期绑定也是固有的。 有些语言同时提供这两种功能，但所使用的特定类型将与正在执行的特定构造相关联。
Early binding vs. Late Binding is really a function of language architecture. Early binding means that code can be built where a machine instruction just jumps to an address and starts executing from there (possibly via a lookup table). Late binding requires a symbol and type reference to be looked up (usually a hash table lookup) for each access, which slows the language down.
While some VM-based languages such as Java are early bound native machine code can only really do early binding directly. To do late binding it has to do the same sort of hash lookup as a dynamic language interpreter would. The late binding then requires a chunk of code to be executed to get the address (this is how OLE automation works). It cannot be done directly by the CPU - the code has to be executed.
Note that the code doing the late binding will actually have its own early bound branch targets in the hash lookup function and so forth. So, from this perspective, early binding is necessary for any code that is to be directly executed by the CPU. Late binding must be done in software.
Early binding is also necessary for quite a wide variety of code optimisations.
Architectures such as C have a sweet spot in writing code close to the metal, as it were. Where you want to do this the early binding aspect is pretty much inherent to the architecture of the language. In a late bound language such as Python the late binding is also inherent. Some languages offer both, but the particular type used will be tied to the particular construct being executed.
我认为有更好的方法/模式来避免不适当的耦合，例如控制反转、依赖注入、工厂……
但是，我喜欢后期绑定的“易于使用”版本独立性
只需使用
后期绑定即可找出 Excel.Application 的类型以及从何处获取它...
I think there are better ways/patterns to avoid inappropriate coupling, like inversion of control, dependency injection, Factories, ...
But, I like the "easy to use" version independence of late binding
Just use
and Late binding will figure out, what kind of Excel.Application, and where to get it from...
编译时绑定，其中在编译期间执行链接称为早期绑定
动态绑定，其中在调用函数时执行期间执行的函数链接称为后期绑定
compile time binding in which linking is performed during the time of compilation is known as early binding
dynamic binding in which linking of function performed during the execution when function is called is known as late binding