早期绑定对比后期绑定：相对优势和劣势是什么？

Question

在讨论计算机语言的演变时，Alan Kay 说他的 Smalltalk 的最重要的一个属性是后期绑定；它赋予语言可塑性和可扩展性，并允许随着时间的推移重构不适当的耦合。你同意？早期绑定是否存在补偿优势，可以解释为什么它似乎是可以使用其中任何一个的领域的两种范式的主导？

我的个人经验（不够广泛或不够深入，不足以具有权威性），基于使用 javascript、jQuery、jsext、actionscript、php、java、RoR 和 asp.net 实现 Web 应用程序，似乎表明后期绑定和膨胀之间存在正相关关系减少。我确信早期绑定有助于检测和防止一些类型安全错误，但自动完成和良好的 IDE 以及一般良好的编程实践也能起到同样的作用。因此，在我的风险规避方面恢复我的理性观点之前，我倾向于发现自己支持后期约束方面。

但我真的不知道如何平衡权衡。

Answer 1

传统上早期绑定的一大优势是性能：后期绑定的语言必须携带在运行时其所有数据类型的信息，而失去机会在编译的时候做一些优化。这种差异已经成为显著少得多，但是，随着计算机变得更快，并为虚拟机变得更聪明有关的飞行优化。

Answer 2

根据我对这两种高性能软件的经验（例如游戏、数字运算）和性能中立的软件（网站、大多数其他东西），有一个 巨大的 后期绑定的优点：您提到的可延展性/可维护性/可扩展性。

早期绑定有两个主要好处。首先：

• 运行时性能

这是普遍接受的，但通常无关紧要，因为在大多数情况下，可以通过硬件来解决问题，而且成本更便宜。当然，也有例外（例如如果您不拥有正在运行的硬件）。

早期绑定的第二个好处：

• 易于开发

似乎被低估了。在开发人员使用其他人的组件的大型项目中，IDE 可以读取早期绑定并使用它们来通知开发人员（通过自动完成、文档等）。这对于后期绑定不太实用，因为绑定是在运行时创建的。如果 IDE 可以从代码推断结构定义，那么使用后期​​绑定语言仍然是可能的，但由于结构总是可以在运行时更改，因此它不太可靠。

易于开发是一件大事。它可以最大限度地减少程序员昂贵的时间——而且您的开发团队越大，它就变得越重要。您需要平衡这一点与后期绑定语言所获得的灵活性。

Answer 3

早期绑定与后期绑定是真的语言架构的功能。早期绑定意味着代码可内置其中机器指令只是跳到一个地址并开始执行从那里（可能通过一个查找表）。后期绑定需要为每个访问，这减慢了语言下一个符号和类型参考要查找（通常是一个哈希表查找）。

虽然一些基于虚拟机的语言如Java的早期绑定本机代码只能真正做早期绑定直接。要做到后期绑定它必须做同样的哈希查找的是一个动态语言解释会。后期绑定，然后需要的代码块被执行，以获得地址（这是自动化如何OLE作品）。它不能由CPU直接完成 - 该代码已被执行。

请注意，该代码执行绑定，逾期将实际拥有的哈希查找功能等等自己的早期绑定分支目标。因此，从这个角度来看，早期绑定是必要的是要由CPU直接执行的任何代码。后期绑定必须在软件中完成。

早期绑定还需要相当长的多种码的优化。

架构如C具有在编写代码接近金属，因为它是最有效点。要做到这一点，早期绑定方面是相当多的固有语言的架构。在后期绑定的语言如Python绑定后期也是固有的。某些语言中同时提供的，但所使用的特定类型将被捆绑到正在执行的特定构建体。

Answer 4

晚暴食允许运行的系统来扩展本身。例如，系统启动时寂寂狼队。随着时间的推移一个evolveDomesticate（）方法，在狼（？），自旋被称为狗新类，实例化，现在我们有狗。 Smalltalk的将节省整个系统的图像，所以如果你将其关闭并重新启动，狗仍然会重新启动后存在。一旦演变为对特定的硬件上运行的对象，并连接成网状网络有整个生态系统没有真正的关机（直到太阳炸毁）。我认为这是艾伦·凯在说的后期绑定的优势，成为了神。

Answer 5

我认为有更好的方法/模式，以避免不适当的耦合，像控制反转，依赖注入，工厂，...

不过，我喜欢后期绑定结果的“易用”版本独立性 只要使用

var excel = CreateObject("Excel.Application");

和后期绑定会弄清楚，什么样的Excel.Application，并从哪里...得到它

Answer 6

编译时间绑定，其中在编译的时候进行链接被称为早期绑定

动态结合在其中的，当调用函数的执行期间执行的功能链接被称为后期绑定