这个问题与
Java集合有关 – 特别是Hashtable和Vector – 但也可能适用于其他地方.
我在很多地方都读到了编程接口的好处,我同意100%.例如,在不考虑底层实现的情况下编程到List接口的能力对解耦和测试目的肯定是有帮助的.考虑到内部存储结构,随机访问时间等方面的差异,我可以看到ArrayList和LinkedList如何适用于不同的环境.然而,这两个实现可以在同一个接口下使用…是很棒的.
我似乎无法放置的是某些同步实现(特别是Hashtable和Vector)如何适应这些接口.对我来说,他们似乎不适合这个模型.大多数底层数据结构实现似乎在数据存储方式(LinkedList,Array,排序树等)方面有所不同,而同步则处理可以访问数据的条件(锁定条件).让我们看一个方法返回Map集合的示例:
public Map getSomeData();
让我们假设应用程序完全不关心并发性.在这种情况下,我们对该方法通过接口返回的任何实现进行操作……每个人都很高兴.世界是稳定的.
但是,如果应用程序现在需要关注并发性前端怎么办?我们现在无法在不考虑底层实现的情况下运行 – Hashtable会很好,但其他实现必须满足.让我们考虑3个场景:
1)在使用集合添加/删除时,使用同步块等强制执行同步.但是,如果同步实现(Hashtable)被返回,这不会是过度杀伤吗?
2)更改方法签名以返回Hashtable.然而,这将我们与Hashtable实现紧密联系在一起,因此,编程到界面的优势被抛到了窗外.
3)利用并发包并更改方法签名以返回ConcurrentMap接口的实现.对我来说,这似乎是前进的方向.
从本质上讲,似乎某些同步实现在集合框架中有点不合适,因为当对接口进行编程时,同步问题几乎迫使人们考虑底层实现.
我完全忽略了这一点吗?
谢谢.