我正在使用Java 6.
有时候我发现自己在做这样的事情。
Map<String,List<Integer>> myMap;
这只是一个例子。它可以更深入。
创建新界面并执行此操作有哪些优点和缺点？
Map<String,NewInterface> myMap;
我唯一看到的是它更具可读性。在性能，模块化，耦合或您的名字方面还有其他什么？
答案 0 :(得分：2)
在您的示例中，如果您在组件List周围进行复杂的逻辑操作，则可能需要围绕它进行包装，只是为了增加模块性并简化测试。
但如果你做的很简单，那么你可能不需要它。
但是你确实指出存在更复杂的情况，所以Id说抽象的。
你指出了抽象子结构的另一个好处 - 可读性。
可读性可能是大型软件项目的关键。它使代码保持清洁并使其更易于维护。很难理解巨大子结构背后的意图。当代码可以自我记录时，你不希望有人花半天的时间来确定你正在做什么。
答案 1 :(得分：0)
首先，List<Integer>显然不会实现您的新界面。您的代码中可能有许多位置，其中变量的类型为List<Integer>。简单的Map<String, List<Integer>>可以立即容纳这些列表，但是您的界面版本需要修改代码中的所有这些位置，而是实例化一些新的自定义版本的List<Integer>，它还实现了您的自定义界面。
这只是一个问题，因为您选择了一个无法修改的JDK类作为示例。如果您正在处理自己可以自由修改的类，那么抽象接口是一种很好的方法。生成的代码通常更容易阅读，因为它可以帮助最大限度地减少泛型通配符的使用。
答案 2 :(得分：0)
即使对于单个集合，您也应该考虑为其引入抽象。毫不奇怪，当你成长软件时，你需要新的抽象。
反对引入抽象，它增加了额外的代码。至少在短期内。
一些受人尊敬的人采取极端的观点，你应该直接进行抽象，永远不要归还一个集合。
普通的企业程序员避免任何面向对象。
答案 3 :(得分：0)
使用新界面会在屏幕上显示较少的字符，但它可能会中断您实际需要关联多种类型的情况。
public class Graph<T> {
private Set<T> nodes;
private Map<T, List<T>> edges;
}
如果我创建了一个界面
public interface NodeList implements List<T> {
}
它会降低可读性并可能允许错误，因为您无法保证
中的NodeList private Map<T, NodeList> edges;
与Map的T值相同。例如：
edges = new Map<Cities, NodeList>(new NodeList<States>());
这显然不是预期的。
答案 4 :(得分：0)
你应该总是编程到最通用的抽象，为你提供所需的东西。如果不需要订购内容，请接受Map<String, ? extends Collection<Integer>。如果您不需要知道大小，查找元素等，但只需要能够迭代元素，请使用Map<String, ? extends Iterable<Integer>>。
不要通过创建没有意义的界面来降低代码的灵活性和耦合性。详细程度只是在这里开展业务的成本。不要让它让你陷入糟糕的设计。