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

如果说“使用继承，您将被锁定在有关代码行为的编译时决策中”，这意味着什么呢

有些语言非常静态，只允许 指定两个类之间的继承关系 这些类的定义时间。对于C++，定义时间是 实际上与编译时间相同。（这两种情况略有不同 Java和C#，但不是很多。）其他语言允许更多 类（和类）关系的动态重新配置 对象（Javascript中的对象）相互关联；有些甚至允许 要修改的现有对象的类，或 要更改的类。（这可能会导致整个逻辑混乱，但也可能 很好地模拟了现实世界的丑恶。）

但重要的是将其与构图进行对比，其中 一个对象和另一个对象之间的关系不是由它们的属性定义的 类关系（即它们的类型），而不是通过引用 相互之间的关系。一般作文是一个非常重要的问题 排列对象的强大且普遍的方法：当一个对象 需要了解另一个人，它有一个参考 其他对象，并根据需要对其调用方法。只要你 开始寻找这个超基本模式，你会找到它的 绝对无处不在；避免它的唯一方法就是把一切 在一个物体上，这将是非常愚蠢的！（还有更严格的规定 UML组合/聚合，但这不是GoF的书 在那里谈论。）

组合关系的一个特点是 特定对象不需要彼此硬绑定。这个 混凝土对象的模式非常灵活，即使在非常静态的环境中也是如此 像C++这样的语言。（让事物保持静止是有好处的： 可以更仔细地分析代码，至少可以 可能-以更少的开销发布更好的代码。）概括一下， Javascript和许多其他动态语言一样，可以假装它 根本不使用编译；当然，只是假装，但是 基本语言模型不需要转换为固定语言 中间格式（例如，“磁盘上的二进制可执行文件”）。那个 编译是在运行时完成的，可以很容易地重做 如果事情变化太大。（有趣的是，这么好的 编译工作可以完成，甚至可以从一个非常动态的 基础…）

一些GoF模式只有在语言的上下文中才真正有意义 那里的事物是相当静止的。没关系；这只是意味着不是全部 必须列出影响图案的力。关键之一 关于研究模式的要点是它帮助我们意识到这些 重要的区别和注意事项。（其他模式更为普遍。 睁大眼睛看那些东西。）