我正在阅读这本书（Head First Object Oriented Design & Analysis）。在第 5 章中有一个建议，我想对它提出一些其他的建议。书上说：
"当你有一组属性时 因对象而异，请使用 集合，就像一个地图来存储那些 动态属性。”
还有一些解释为什么要这样做：
“你会从 你的课程，避免不得不 新属性时更改代码 已添加到您的应用中”。
我确实了解这种方法的优点，但不是也有缩小尺寸吗？我的意思是如果我使用映射来存储这些信息（在示例中它是一个字符串到枚举映射）并提供一个 getProperty(String) 方法来访问，那么这个方法的调用者实际上必须知道哪些字符串是允许的。我不喜欢这个。我的意思是，您当然可以争辩说可以在 javadoc 中说明允许输入的内容。
这真的是处理这类问题的方法吗？还有其他选择吗？我知道用继承来做这件事是不好的，因为有大量的子类，而且这些子类不会覆盖任何东西，只是添加新的属性，这在我看来真的不是那么好。
【问题讨论】：
我个人认为使用Map 代替实际字段是一个糟糕的主意。我很不幸与广泛使用这种（反）模式的系统一起工作，维护起来简直就是一场噩梦。
我认为绝对没有理由将地图用于“面向未来”，您可以避免添加新方法的论点是可笑的，尤其是当您考虑到添加新字段需要大约 20 次击键时，添加 getter 和 setter再点击 3-4 次鼠标。你得到的是什么，你失去的是类型安全和编译时检查，控制和监视正在设置的内容和时间的能力，更不用说你打破了封装原则。
还应该注意的是，Java 语言本身的开发已经朝着越来越多的编译时检查方向发展，枚举和泛型是这个方向最明显的例子。全部扔掉比1.3-1.4时代还要糟糕
只有在真正动态的情况下才应该使用映射，即在编译时无法知道键列表。
【讨论】：
您可以实现 getProperty 方法以接受 enum 值作为键。这将提供一种简单的方法来向用户显示哪些键是有效的，当您想要添加更多时，您甚至不必修改原始的 enum，因为您可以扩展 enum。当然，修改原始的 enum 可能会更容易，因为拥有 enum 继承层次结构有点令人困惑。
【讨论】：
是的，您必须知道检索数据的密钥。不，这不会导致任何根本性的变化；如果您使用类层次结构，则需要知道要调用的类和方法的名称。
请注意，您可以一些使用地图中的项目而无需预先知道名称 - 您可以遍历地图并（例如）向用户显示值，允许修改，并让他们将特定键应用于特定设置。
我并不是说这一定是个好主意，但不管是不是好主意，都可以做到。
【讨论】：