关于封装的问题（书籍：HF OOA&D）
我正在读这本书（Head First Object Oriented Design & Analysis）。在第五章中有一个建议，我想对此有一些其他的看法。书上说：
“当你有一组属性时 因对象而异，请使用 集合，例如存储这些的 Map 动态属性。”
此外，还有一些解释为什么要这样做：
“您将从中删除很多方法 您的课程，并避免必须 新属性时更改代码 添加到您的应用程序中”。
我确实理解这种方法的优点，但不是也缩小了尺寸吗？我的意思是，如果我使用映射来存储这些信息（在示例中它是一个字符串到枚举映射）并提供getProperty(String) 方法来访问，该方法的调用者实际上必须知道允许哪些字符串，我的意思当然是你可以在 javadoc 中说明允许哪些输入。 。
这真的是处理此类问题的方法吗？有其他选择吗？我知道用继承来做到这一点并不好，因为大量的子类并且这些子类不会覆盖任何内容，而只是添加新的属性，这确实不太好 在我看来。
i'm reading this book (Head First Object Oriented Design & Analysis). In chapter 5 there is a suggestion which i would like to have some other toughts about it. The book says:
"When you have a set of properties
that vary across your objects, use a
collection, like a Map to store those
proeprties dynamically."
and further more, some explaination why to do it:
"You'll remove lots of methods from
your classes, and avoid having to
change your code when new properties
are added to your app".
I do understand the advantage of this approach but isn't there a downsize as well? I mean if i use a map to store those informations (in the example it was a String to Enum map) and provide a getProperty(String) method to access, the caller of this method actually has to know which Strings are allowed. I don't like this somehow. I mean of course you can argue that it could be stated in the javadoc which input is allowed.
Is this really the way to deal with this kind of problem are there any alternatives? I understand that doing this with inheritence is not good because of the bulk of subclasses and those subclasses would not override anything just add new properties which really isnt that good in my opinon.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我个人认为使用
Map而不是实际字段是一个糟糕的主意。我很不幸地使用了广泛采用这种（反）模式的系统，并且维护起来是一场噩梦。我认为绝对没有理由使用映射来“面向未来”，认为可以避免添加新方法的论点是可笑的，特别是当您考虑到添加新字段需要大约 20 次击键，为其添加 getter 和 setter 又需要 3 次时-4 次鼠标点击。你得到的是什么，你失去的是类型安全和编译时检查，控制和监视设置内容和时间的能力，更不用说你打破了封装原则。
还应该指出的是，Java 语言本身的发展已经朝着越来越多的编译时检查的方向发展，枚举和泛型是这个方向最明显的例子。把它全部扔掉比 1.3-1.4 时代更糟糕。
只有当某些东西真正动态时才应该使用映射，即在编译时不可能知道键列表。
I personally think that using a
Mapinstead of actual fields is a terrible idea. I had the misfortune to work with systems that employed this (anti)pattern extensively and it was a nightmare to maintain.I see absolutely no reason to use maps for "future proofing", the argument that you can avoid having to add new methods is laughable, especially when you consider that adding a new field takes about 20 keystrokes, adding getters and setters for it another 3-4 mouse clicks. What you gain is nothing and what you lose is type safety and compile time checking, the ability to control and monitor what is being set and when, not to mention the fact that you break the principle of encapsulation.
It should also be noted that the development of the Java language itself has been moving towards more and more compile time checking, enums and generics being the most obvious examples of this direction. To throw it all away is even worse than it was in the 1.3-1.4 era
Maps should only be used when something is truly dynamic, i.e. there's no way the list of keys can be known at compile time.
您可以实现
getProperty方法来接受enum值作为键。这将提供一种简单的方法来向用户显示哪些键是有效的，当您想要添加更多键时，您甚至不必修改原始的枚举，因为您可以扩展枚举。 /代码>。当然，修改原始的枚举可能会更容易，因为拥有枚举继承层次结构有点令人困惑。You can implement your
getPropertymethod to accept anenumvalue as the key. This would provide an easy way to show the user which keys are valid, and you wouldn't even have to modify the originalenumwhen you wanted to add more since you can extend theenum. Granted, it might just be easier to modify the originalenumas it is kind of confusing to have anenuminheritance hierarchy.是的，您必须知道检索数据的密钥。不，这不会造成任何根本性的改变；如果您使用类层次结构，则需要知道要调用的类和方法的名称。
请注意，您可以在不预先知道名称的情况下使用地图中的某些项目 - 您可以迭代地图并（例如）向用户显示值，允许修改，并让他们将特定的键应用于特定的设置。
我并不是说这一定是个好主意，但无论好坏，它都是可以做到的。
Yes, you'd have to know the keys to retrieve the data. No, this wouldn't cause any fundamental change; if you used a class hierarchy, you'd need to know the names of the classes and methods to call.
Note that you can make some use of items in a map without knowing the name up-front -- you can iterate through the map and (for example) show values to the user, allow modification, and let them apply particular keys to particular settings.
I'm not saying this is necessarily a good idea, but it can be done whether it's a good idea or not.