java与新接口相比，嵌套模板的优点和缺点是什么？

Question

我正在使用Java6

有时我发现自己在做这样的事情

Map<String,List<Integer>> myMap;

这只是一个例子。它可以更深入

创建一个新界面并改为这样做的利弊是什么

Map<String,NewInterface> myMap;

我唯一看到的是它更具可读性。在性能、模块化、耦合或你所说的方面还有什么问题吗

Answer 1

使用一个新的界面将在屏幕上显示更少的字符，但它可能会破坏您实际希望将多种类型关联起来的场景

public class Graph<T> {

  private Set<T> nodes;

  private Map<T, List<T>> edges;

}

如果我做了一个界面

public interface NodeList implements List<T> {

}

它会降低可读性，并可能允许出现错误，因为您无法保证节点列表在

  private Map<T, NodeList> edges;

使用与映射相同的值T构建。例如：

edges = new Map<Cities, NodeList>(new NodeList<States>());

这显然不是本意

Answer 2

即使对于单个集合，也应该考虑为其引入抽象。毫无疑问，随着OO软件的发展，您需要新的抽象

为了避免引入抽象，它添加了额外的代码。至少在短期内

一些受人尊敬的人持极端观点，认为你应该直接追求抽象，永远不要归还收藏品

一般的公司程序员都避免任何面向对象的东西

Answer 3

你应该总是按照最一般的抽象来编程，从而得到你需要的东西。如果内容不需要排序，请接受Map<String, ? extends Collection<Integer>。如果不需要知道大小、查找元素等，只需要能够遍历元素，那么可以使用Map<String, ? extends Iterable<Integer>>

不要通过创建一个毫无意义的接口来降低代码的灵活性和耦合性。冗长只是在这里做生意的代价。不要让它强迫你做一个糟糕的设计

Answer 4

首先，List<Integer>显然不会实现您的新接口。在代码中，可能有很多地方的变量类型为List<Integer>。简单的Map<String, List<Integer>>会立即容纳这些列表，但您的接口版本需要修改代码中的所有位置，以实例化一些新的List<Integer>自定义版本，该版本也实现了您的自定义接口

这只是一个问题，因为您选择了一个无法修改的JDK类作为示例。如果您正在处理自己可以自由修改的类，那么抽象出接口是一种很好的方法。生成的代码通常更易于阅读，因为它可以帮助最小化泛型通配符的使用

Answer 5

在您的示例中，如果您在组件列表中有复杂的逻辑操作，那么您可能需要在其周围包装一些东西，以增加模块性并简化测试

但是如果你所做的很简单，那么你可能不需要它

不过，你确实指出还有更复杂的情况，所以我要说的是抽象

您指出了将子结构抽象出来的另一个好处——可读性

可读性是大型软件项目的关键。它保持了代码的整洁，并使其更易于维护。很难理解巨大的下部结构背后的意图。你不想让一个不得不维护这些代码的人花半天的时间弄清楚你在做什么，而代码可以自我记录