我想知道编译时决策的含义

Question

说“继承你被锁定在关于代码行为的编译时决定”是什么意思。

Answer 1

我建议来自Donal Fellows on Programmers，

的帖子

  

有些语言非常强烈，只允许使用   在两个类之间的继承关系的规范   定义这些类的时间。对于C ++，定义时间是   几乎和编译时间一样。 （它略有不同   Java和C＃，但不是很多。）其他语言允许更多   动态重新配置类的关系（和类似的   Javascript中的对象）;有些人甚至允许   要修改的现有对象的类，或者a的超类   要改变的课程。 （这可能导致完全逻辑混乱，但也可能   模拟真实世界的恶作剧。）

     

但重要的是将其与构图形成鲜明对比   一个对象与另一个对象之间的关系不是由它们定义的   类关系（即它们的类型），而不是引用   每个都与另一个有关。一般的构成是非常的   强大而无处不在的排列对象的方法：当一个对象时   需要了解另一个，它有一个参考   其他对象并根据需要调用其上的方法。只要你   开始寻找这种超级基本模式，你会发现它   绝对无处不在避免它的唯一方法是放置一切   在一个物体中，这将是非常愚蠢的！ （还有更严格的问题   UML组合/聚合，但这不是GoF书籍   谈论那里。）

     

关于构图关系的一个问题是   特定对象不需要彼此硬约束。该   具体物体的图案非常灵活，即使在非常静止的情况下   像C ++这样的语言。 （让事情变得非常静止有好处：   可以更密切地分析代码 - 至少   潜在的 - 以更少的开销发出更好的代码。）回顾一下，   与许多其他动态语言一样，Javascript可以假装它   根本不使用汇编;当然，只是假装，但是   基础语言模型不需要转换为固定的   中间格式（例如，“磁盘上的二进制可执行文件”）。那   完成的编译是在运行时完成的，可以很容易地重做   如果事情变化太大。 （令人着迷的是这么好   编译工作可以完成，甚至从非常动态开始   基础...）

     

一些GoF模式在语言环境中才真正有意义   事情是相当静止的。没关系;它只是意味着并非全部   必须列出影响模式的力量。其中一个关键   关于学习模式的要点是它有助于我们意识到这些   重要的差异和警告。 （其他模式更普遍。   请留意那些人。）