我正在开发一个与 JSON API 进行通信的 iPhone/iPad/Android 应用程序。
该应用程序版本的第一个版本已经完成，现在正在进行其他开发阶段。在其他阶段，应用程序需要与新版本的 API 集成，并允许用户访问其他功能，例如新屏幕或现有屏幕中修改的行为。然而，该应用程序确实需要向后兼容以前版本的 API。
解决此类要求的最佳实践是什么？
我可以对整个代码进行检查：
if (APIVersion == 1) {
} else if (APIVersion == 2) {
} else if (APIVersion == ....) {
}...
但我担心这种方法的可扩展性。
我想到了工厂方法，但我不确定这能让我走多远。
谢谢，
标记
新 API 版本的发布是很稀少事物。通常，您只需添加新的可选参数或新方法即可实现向后兼容性。例如，如果您有名为search，但是现在你对它的工作方式不满意，你可以通过多种方式来处理：
如果更改很简单，您可以添加新的mode参数默认为mode1（所以它是向后兼容的）。如果用户提供mode2你用适当的方法检测到它if条件按照你自己的建议。 （此外，通常您可以想出比“模式”更好的名称。）
如果改动较大，可以添加新的search2使用新界面的服务。然后你标记search方法已被弃用（但仍然有效并且向后兼容）。通常当你这样做时，你可以refactor你的代码以这样的方式，几乎所有的逻辑都在search2方法，和你的旧方法search方法调用search2在内部使用修改后的参数（并适当地重新格式化结果）。如果你正确地做到了这一点，你将永远不需要改变search方法不再了。当您更改表格等时 - 您只需要修改search2.
我的观点是，避免释放N+1API 的 -st 版本。如此大的发布意味着重大变化ALL您的方法，而不仅仅是一种。许多主要 API 从未发布其 API 的版本 2，它们仍然使用版本 1，只是稍微修改了其中的部分内容，如上面的示例所示。
如果你是绝对确定关于释放N+1-st 版本的 API，创建新的入口点ALL你的方法。如果您有一个名为services，新建一个名为services-v2。重构你的services代码，以便它使用大部分services-v2。如果你认为这太过分了，那么我认为你不需要N+1-st 版本的 API 还没有。
顺便说一句，不要混淆集中式 API（如 Google 地图）和分布式 API（如 Android）。 Android一直在发布新的API版本，因为Android服务器有数十亿台（每台Android设备都是一台），而且它们都不能简单地由Google远程升级。Android 的下一版本仍然向后兼容上一版本，数字的增加只是为了表明新功能。例如。您仍然可以在 Android 7.0 上运行为 Android 3.0 构建的应用程序（用户可能会收到一些额外的警告，但应用程序将运行）。 Android 应用程序开发人员使用这些数字来描述其应用程序的“最低要求”。然而，集中式 API 通常会增加其版本号以指示主要的向后不兼容的更改.
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
