我试图理解为什么这样实现了
java.util.Properties.它有两个接口：getProperty / setProperty,它只接受字符串,并将/ get接受任何对象作为值.这两个接口似乎是重叠的,所以使用getProperty()可以检索一个带有put()的字符串.
这个奇怪的混合界面似乎有一些问题.放置覆盖字符串属性的对象具有清除字符串值的副作用,生成null作为getProperty结果.添加一个整数或一些其他具有简单字符串转换的值可能会被误解为是一个实际的属性值(但作为属性始终为空).
我的问题是：真的有实际的理由吗？还是我怀疑是一个半烤的实施？
解决方法
Joshua Bloch在
Effective Java中明确提到了这一点
[from Chapter 4] In the case of
Properties,the designers intended that only strings be allowed as keys and values,but direct access to the underlyingHashtableallows this invariant to be violated. Once this invariant is violated,it is no longer possible to use other parts of the Properties API (loadandstore). By the time this problem was discovered,it was too late to correct it because clients depended on the use of nonstring keys and values.
该文本在使用组合超过继承的上下文中.他基本上使用这个作为使用组合而不是继承的例子.如果属性包含地图而不是扩展地图,那么它可以强制使用String作为键和值的invarient.
所以答案是：这是一个监督.
