我们开发了一个flex组件，现在它被多个Web应用程序使用。 我们发现一些回调是旧的，他们有错误的论点。 例如，当它们用于设置一些参数时，它们会占用一个对象，而当它们获得相同的参数时，它们会使用另一个对象。 我们希望使这些函数在设置和获取参数时保持一致。 因此，我们开始考虑使用新名称和正确的参数开发新的getter和setter。 无论如何，由于该组件被许多其他应用程序使用，我们无法重命名回调，也没有更改其实现，我们可能会遇到其他Web应用程序的问题。 因此，我们想知道是否有某种方法可以使Flash暴露的回调不被使用，因此使用这些方法的人会看到一些警告并开始替换未弃用的版本。 提前感谢您的回答！
答案 0 :(得分：4)
一旦API，始终是API。
您不能只从API中删除内容，否则当前使用这些命令的应用程序将失败。只需添加新的替换API并保留旧的替代API。在文档中陈述旧的已弃用并且有更好的命令。
这方面的一个例子是jQuery的live()和delegate()被on()取代。虽然已弃用，但{1}}和live()仍然存在于1.7以适应旧API，特别是对于那些升级了库但使用过时的，未维护的插件的人。
你也可以这样做。您可以为旧API显示相同的接口，但在其下面，它使用新的API实现，但稍作修改。这样，你就不会重复你的代码了。
例如，我们来看看jQuery delegate()，delegate()和live()。这些不是这些方法的实际代码，但我遵循弃用的概念（我不能想到除on()，delegate()和live()之外的其他弃用示例）。
on()答案 1 :(得分：1)
很少有不清楚的事情：
谁在构建代码的Flash端？使用该组件的人，或者他们是否编译并且不知道内部是什么？
观众一般有多精明？
使用该组件构建的应用程序的一般使用寿命是多少。您是否明确了您的版本政策？
IMO： （这意味着这只是我的观点，不是绝对的事实，这种方法对于Linux开发来说更为典型，但对于Windows来说却是可怕的/非典型的）。
现在，如果您的用户正在构建您的代码，我会说直接针对2-3个次要版本发布[Deprecated()] meta并在此之后删除它，当然不要将其拖到主要版本发布中。如果你有一个带宽可以为旧版本提供一些支持，并且可能会发布补丁，但改进更为重要。某些策略可能有所帮助。例如，如果用户接触到测试版产品，他们就更有可能更快地采用这种变化。
如果您的观众大多是精明/有良好的社区沟通，可能只需要一个小版本就足够了 - 最坏的情况是旧版兼容版本会留下很少的东西。再说一遍，如果您有旧版本的补丁，那将是很好的，但是你会通过保持错误的API绑定你的手，并且在一段时间之后由于该API，你的用户会认为你的应用程序是一个过时的废话，它会阻止他们使用它们宁愿改变。
仅承诺次要版本之间的一致性非常重要。当然，如果你可以保持向后兼容多个版本是一件好事，但这是一个奖励而不是要求。虽然从表面上看，使用您产品的其他人可能不愿意采用这种改变，但另一种选择仍然更糟。应该有一些合理的时间，这符合平均应用程序的使用寿命，为您提供支持。一些不会使普通应用程序在它变得有用之前就已经过时的东西，但所有东西都是适度的。