我正在读这本书(Head First Object Oriented Design&Analysis).在第5章中有一个建议,我想对此有一些其他的强硬态度.这本书说:
"如果您有一组不同对象的属性,请使用集合(如Map)动态存储这些属性."
更进一步,解释为什么这样做:
"您将从类中删除大量方法,并避免在将新属性添加到应用程序时更改代码".
我确实理解这种方法的优点但是也没有缩小尺寸吗？我的意思是如果我使用地图来存储这些信息(在示例中它是一个String to Enum map)并提供一个getProperty(String)方法来访问,这个方法的调用者实际上必须知道允许哪些字符串.我不喜欢这个.我的意思是你当然可以争辩说可以在javadoc中说明哪个输入是允许的.
这真的是处理这类问题的方法有没有其他选择？我知道用继承做这件事并不好,因为大量的子类和那些子类不会覆盖任何东西只是添加新的属性,这在我的意见中并不是那么好.
我个人认为使用Map而不是实际字段是一个可怕的想法.我不幸地使用了广泛使用这种(反)模式的系统,这是一个维持的噩梦.
我认为绝对没有理由使用地图进行"未来验证",你可以避免添加新方法的论点是可笑的,特别是当你考虑添加一个新字段需要大约20次击键时,为它添加另外3个getter和setter 3 -4点击鼠标.你获得的是什么,你失去的是类型安全和编译时间检查,控制和监视正在设置什么以及何时的能力,更不用说你打破了封装原则的事实.
还应该注意的是,Java语言本身的开发已经朝着越来越多的编译时检查,枚举和泛型是这个方向最明显的例子.扔掉它比在1.3-1.4时代更糟糕
只有在某些东西是真正动态的时候才能使用映射,即在编译时无法识别密钥列表.