PropertyResourceBundle 是一种 Java 机制，用于从实际的 Java 代码中分离出特定于语言环境的文本。当应用程序调用这些特定于语言环境的其中一个属性时，与给定的用户语言环境相关的一个文本文件就被打开并被阅读。
从 Java 代码中分离出对语言环境敏感的消息是处理国际化问题的关键。只要应用程序使用 PropertyResourceBundle 来获取它特定于语言环境的属性，就可以通过为所有受支持的语言环境提供属性文本文件而将应用程序很容易地翻译成任何语言。
维护大量的资源束会是一项十分艰巨的任务 ― 就象努力维护一大段代码一样令人生畏。那么为什么不应用一些在代码中使用的原理来促进资源束的重用呢？
本文的重点是为 PropertyResourceBundle 引入继承概念。以这种方式，公共束就可以被共享，而可以在不影响其它的束用户的前提下，引入更多特定的束。
首先，我将概括地叙述一下最普遍使用的设计策略。
当前的策略及它们的问题
当前使用 PropertyResourceBundle 的设计通常遵循以下三个策略：
使用一个大的、囊括一切的束（所有应用程序组件都共享这个束）。
允许每一个应用程序组件拥有自己独立的束，这些束不在应用程序间重用。
允许一些不具有重复属性定义的资源束。
让我们更详细地看一下其中的每一种策略：
单束：不重用，维护代价高
第一种方法在有关设计时和运行时的资源束上都有很大的争议。它并不支持重用，因为只存在一个束且对该束所做的任何更改都会影响到使用该束的其它组件。
这种方法中的任何属性的重新定义都要求所有组件使用新版本，或者添加一个新属性。无论如何，维护大量资源束会很快变得很吃力，而且消耗的时间比您所希望的要多。
更小的，独立的束：不重用，使问题一致
第一种方法的另一种选择是将单资源束分裂成原始束的一些子集。这种方法将使每一个束独立于其它束；允许每一个束重新定义属性以供自己使用。
这种设计不支持重用，因为每一个束都必须定义它自己的属性。而且每一个束在其定义中都保留独立性。
各个束之间保持一致现在变得更困难，因为每一个束都是独立的。比如每一个束可能都定义一个带有邮件地址的属性。如果这个地址现在发生了更改，每一个与此邮件地址有关的束都必须改变。
特定于属性的束：维护的高代价转向代码
第三种方法依赖于代码开发人员要明确了解给定任何属性时要转向哪一个资源束。
使用邮件地址属性示例（其中地址属性只在一个资源束中定义）时，任何需要包含地址的应用程序组件都必须转到定义地址的特定资源束。在这种模式下，应用程序组件必须确定给定一个键时，要转到哪一个资源束。对资源束所做的任何更改都可能要求对使用它们的应用程序组件进行类似的更改。
使用这种方法时，维护问题真的刚好从资源束转到获取属性的代码上了。
为了寻求一个有效的解决方案，我们需要在这三种方法中权衡利弊。