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