java - 为什么要使用字符串标识符来访问资源数据？

Question

我正在开展一个项目来替换已弃用的资源管理系统(Mac 和 Windows 上的 QuickTime 资源管理器)，并且我一直在使用 Qt 使用的当前模型，其中使用字符串从资源文件中检索数据键。

例如，我的资源文件中可能有一个图像，“HungryBear.png”存储在我的资源文件中。 Qt 和我建议的系统将以伪代码描述的方式获取它:

image = GetImageResource("BearPlugin/Images/HungryBear.png");

此时很清楚该图像是什么，以及在哪里可以找到它。

在我们当前的系统中，我们使用数字。数字的问题在于必须查找资源文件(可能有很多)才能找出它是什么图像(或资源)。

一个这样的例子:

oldActiveResourceFile = GetActiveResourceFile(); // think of a stack of resource files

SetActiveResourceFile("BearPlugin");

image = GetImageResource(1);

// Perhaps other resources are retrieved and other functions called
// Possibly introduce problems by calling functions that change "Active Resource File"

SetActiveResourceFile(oldActiveResourceFile);

第一种方法是我在当前访问资源文件数据的系统中看到的。有人告诉我 C# 和 Java 使用它，我知道它们用于字符串键值对等。

但是，我的一位同事对更改当前系统(将这些数字 ID 用于我提议的字符串 ID)表示担忧。似乎有很多好处，它们解决了我们在当前系统中遇到的许多问题。我希望获得所提议的系统更好和更理想的支持文档，所以我的问题是:

您是否知道任何研究或讨论表明在代码中使用字符串标识符(分层)比使用任意数字更好？

注意事项

1. 我计划使用 zip 文件(可能未压缩)来包含数据文件。
2. 我们有一个应用插件环境。应用程序和每个插件都可以有自己的资源文件。插件可能能够访问应用程序资源文件中的资源数据。

3. 以下是一些已考虑且我相信已满足的要求:

   • 软件开发人员应能够唯一标识资源。
   • 软件开发人员应能够使用有意义的名称来命名资源。
   • 资源应与需要它们的应用程序部分相关联。
   • 本地化人员应能够轻松识别已更改的资源文件。
   • 本地化人员应能够使用自己的工具修改资源文件。
   • 如果客户使用的功能依赖于已弃用的调用，则应提醒他们。

Answer 1

使用数字资源 ID 的主要缺点是可发现性(弄清楚资源 1234 是什么)以及随着时间的推移在大型应用程序中添加更多资源时保持 ID 的唯一性。

使用字符串名称作为资源 ID 的主要缺点是字符串在运行时占用更多内存。例如，资源的 .NET 模式使用字符串名称，并且这些字符串名称在运行时标记在可执行文件中。

字符串名称很容易在大型应用程序和多年的修订中保持唯一和 self 记录(在您的示例中使用分层路径)，但好处实际上只是为了方便人类。如果这些字符串可以归结为最终可执行二进制文件的整数 ID，那就太好了，因为此时资源池是不可变的，而且 CPU 实际上更喜欢整数 ID。 .NET 无法以这种方式工作，但其他平台可以。