Java 泛型与接口

我从Java1.4（以前的公司）过渡到Java1.6（新公司）。我所观察到的是，在1.4中，大多数专有框架是使用接口和模板模式定义的，而在1.6中，大多数框架是围绕泛型定义的

虽然我仍在努力掌握泛型，但我的问题是——这是一种正确的设计方法吗？接口使您的设计更加灵活/解耦。而泛型则实现类型安全并强制您传递特定类型的类。在代码解耦方面没有真正的帮助。这是正确的吗

一个例子-

public MyWizard extends SignupWizard<SignupSection, SignupObject, SignupListener, SignupView>{
}

---

我注意到许多新框架倾向于使用注释而不是接口，但我没有注意到它们使用泛型而不是接口（不管它是什么意思-请解释更多）

在泛型的帮助下，当您有一个带有泛型类型参数的接口，并且同一个接口可以用于许多不同的类型时，可以减少一些代码重复并提高类型安全性。包中的集合是泛型有用的一个很好的例子

---

在注释的情况下，有时我觉得它们被过度使用了，接口会更好——例如，使用接口很容易知道方法应该采用什么参数——但在其他情况下，注释更灵活、更强大。

泛型允许您在常规类型上实现方法，而接口只定义签名。也许有时候像Scala的特质一样被滥用，但大多数情况下它们有两个不同的用途。如果一切都是一个接口，那么将有大量重复的代码或委托给某个助手类。

看看Jung2，看看泛型在哪里变得真正强大。基本上，任何对象都可以是顶点或边，这在网络算法中产生了一些非常有趣的想法。仅使用接口是无法做到这一点的

我也不确定你的上述用途是否合适。如果您是从一个对象扩展或实现一个接口，那么您真的不希望像这样传递对象。泛型用于实现抽象类型的类，如集合，它可以作用于任何对象。如果我传递了完全有效的

SignupWizard

，会发生什么

对于这个特定的想法，也许您确实希望使用接口。有一个定义wizardaction的接口，每个实现它的对象和mywizard都能够.addaction（int位置，wizardaction）。事实上，这绝对是一个接口问题

---

我同意其他人的观点——泛型是在库需要时使用的。

我不会说什么是泛型和接口，每一种都有不同的需求和用途。以原始帖子中提到的方式使用通用参数有多种用途。它允许开发人员定义构成类的字段对象类型的基类。使用这种方法，开发人员可以接受类对象作为参数，他们可以在这些参数上使用反射来创建实际对象并设置字段，或者只接受首先要设置的整个对象。与需要类对象而不是执行

newt（）

之类操作相关的问题称为

使用泛型的另一个好处是，在使用超类中的字段或方法时，您不需要一直进行类型转换——您个人知道它们的类型，但Java没有将该类型信息存储在任何地方。另一个好处是，所有getter/setter方法都可以使用泛型参数，并向其他对象公开更合理的前端，这些对象依赖于您在上述对象中设置了专门字段这一事实

使用接口执行泛型所做的相同操作的问题在于，在返回专门类型（或检查传入类型，然后为对象设置字段）之前，您需要其他方法来访问专门类型并强制转换它们。这使得设计更加复杂，对解耦毫无帮助

---

正如我在评论中提到的，任何子类都将设置这些类型参数，并且不会向用户公开任何内容。因此，您可以使用类似于

class MegaSignupWizard Extendes SignupWizard

的东西，并且使用

MegaSignupWizard

可以访问类中的专门方法，而无需强制转换，一切都保持完全有效。现在这很酷：）

我认为是泛型和接口，因为任何接口都可以使用泛型本身。我看到的问题是，当您开始使用泛型（抽象）类时，您将失去使用组合的灵活性。虽然继承本身并没有什么不好的地方，但您必须为它进行设计，而且存在许多陷阱。

注释而不是接口？！这样的框架是什么？例如Servlet3.0API中的@GET注释：@Murali:听说过JPA吗？几乎只有注释。如果顶点和边有一个超级接口，那么对象可以是顶点或边。但是边上不能有类型化参数。你要么使用object，要么坚持使用一种类型，这是完全有效的。任何子类都将设置这些类型参数，并且不会向用户公开任何内容。因此，您可以使用类似MegaSignupWizard的扩展SignupWizard，并且MegaSignupWizard可以访问类中的专门方法而无需强制转换，因此所有内容都保持完全有效。请改进您的示例。例如，SignupWizard的定义是什么？给出一些框架的具体例子，其中泛型的使用方式与您所说的相同。“泛型vs.接口”的问题对我来说没有多大意义，因为它们经常一起使用。“注释与接口”更为合理。看起来我在C++中希望得到的东西，而不是java。对，布洛赫的一点是“有效java”，它是赞成合成而不是继承。我的理论是，每当我看到大量使用通用电气

public interface Wizardable{
  public SignableSection getSection();
  public SignableObject getSignableObject();
...
}

public MyWizard implements Wizardable{
....
}