Generics

Ordinary classes and methods work with specific types: either
primitives or class types. If you are writing code that might be used across more types, this rigidity can be overconstraining.

One way that object-oriented languages allow generalization is through polymorphism. You can write (for example) a method that takes a base class object as an argument, and then use that method with any class derived from that base class. Now your method is a little more general and can be used in more places. The same is true within classes—anyplace you use a specific type, a base type provides more flexibility. Of course, anything but a final class can be extended(Or a class with all private constructors.), so this flexibility is automatic much of the time.
Sometimes, being constrained to a single hierarchy is too limiting. If a method argument is an interface instead of a class, the limitations are loosened to include anything that
implements the interface—including classes that haven’t been created yet. This gives the client programmer the option of implementing an interface in order to conform to your class
or method. So interfaces allow you to cut across class hierarchies, as long as you have the option to create a new class in order to do so.
Sometimes even an interface is too restrictive. An interface still requires that your code work with that particular interface. You could write even more general code if you could say that your code works with “some unspecified type,” rather than a specific interface or class.

This is the concept of generics, one of the more significant changes in Java SE5. Generics implement the concept of parameterized types, which allow multiple types. The term
“generic” means “pertaining(适合; 关于，有关; 附属，从属) or appropriate to large groups of classes.” The original intent of
generics in programming languages was to allow the programmer the greatest amount of expressiveness possible when writing classes or methods, by loosening the constraints on the
types that those classes or methods work with. As you will see in this chapter, the Java implementation of generics is not that broad reaching—indeed, you may question whether the term “generic” is even appropriate for this feature.

If you’ve never seen any kind of parameterized type mechanism before, Java generics will probably seem like a convenient addition to the language. When you create an instance of a parameterized type, casts will be taken care of for you and the type correctness will be ensured at compile time. This seems like an improvement.

However, if you’ve had experience with a parameterized type mechanism, in C++, for example, you will find that you can’t do everything that you might expect when using Java
generics. While using someone else’s generic type is fairly easy, when creating your own you will encounter a number of surprises. One of the things I shall try to explain is how the
feature came to be like it is.

This is not to say that Java generics are useless. In many cases they make code more straightforward and even elegant. But if you’re coming from a language that has implemented a more pure version of generics, you may be disappointed. In this chapter, we will examine both the strengths and the limitations of Java generics so that you can use this new feature more effectively.

Comparison with C++

The Java designers stated that much of the inspiration for the language came as a reaction to C++. Despite this, it is possible to teach Java largely without reference to C++, and I have
endeavored(尝试，试图) to do so except when the comparison will give you greater depth of understanding.
Generics require more comparison with C++ for two reasons. First, understanding certain aspects of C++ templates (the main inspiration for generics, including the basic syntax) will
help you understand the foundations of the concept, as well as—and this is very important— the limitations of what you can do with Java generics and why. The ultimate goal is to give
you a clear understanding of where the boundaries lie, because my experience is that by understanding the boundaries, you become a more powerful programmer. By knowing what you can’t do, you can make better use of what you can do (partly because you don’t waste time bumping up against walls).

The second reason is that there is significant misunderstanding in the Java community about C++ templates, and this misunderstanding may further confuse you about the intent of
generics.
So although I will introduce a few C++ template examples in this chapter, I will keep them to a minimum.

Simple generics

One of the most compelling initial motivations for generics is to create container classes,which you saw in the Holding Your Objects chapter (you’ll learn more about these in the
Containers in Depth chapter). A container is a place to hold objects while you’re working with them. Although this is also true of arrays, containers tend to be more flexible and have
different characteristics than simple arrays. Virtually all programs require that you hold a group of objects while you use them, so containers are one of the most reusable of class
libraries.
Let’s look at a class that holds a single object. Of course, the class could specify the exact type of the object, like this:

//: generics/Holder1.java

class Automobile {}

public class Holder1 {
  private Automobile a;
  public Holder1(Automobile a) { this.a = a; }
  Automobile get() { return a; }
} ///:~

But this is not a very reusable tool, since it can’t be used to hold anything else. We would prefer not to write a new one of these for every type we encounter.
Before Java SE5, we would simply make it hold an Object:

//: generics/Holder2.java

public class Holder2 {
  private Object a;
  public Holder2(Object a) { this.a = a; }
  public void set(Object a) { this.a = a; }
  public Object get() { return a; }
  public static void main(String[] args) {
    Holder2 h2 = new Holder2(new Automobile());
    Automobile a = (Automobile)h2.get();
    h2.set("Not an Automobile");
    String s = (String)h2.get();
    h2.set(1); // Autoboxes to Integer
    Integer x = (Integer)h2.get();
  }
} ///:~

Now a Holder2 can hold anything—and in this example, a single Holder2 holds three different types of objects.

There are some cases where you want a container to hold multiple types of objects, but typically you only put one type of object into a container. **One of the primary motivations for generics is to specify what type of object a container holds, and to have that specification backed up by the compiler.

So instead of Object, we’d like to use an unspecified type, which can be decided at a later time. To do this, you put a type parameter inside angle brackets after the class name, and then substitute an actual type when you use the class. For the “holder” class, it looks like this,where T is the type parameter:

//: generics/Holder3.java

public class Holder3<T> {
  private T a;
  public Holder3(T a) { this.a = a; }
  public void set(T a) { this.a = a; }
  public T get() { return a; }
  public static void main(String[] args) {
    Holder3<Automobile> h3 =
      new Holder3<Automobile>(new Automobile());
    Automobile a = h3.get(); // No cast needed
    // h3.set("Not an Automobile"); // Error
    // h3.set(1); // Error
  }
} ///:~

Now when you create a Holders, you must specify what type you want to put into it using the same angle-bracket syntax, as you can see in main(). You are only allowed to put objects
of that type (or a subtype, since the substitution principle still works with generics) into the holder. And when you get a value out, it is automatically the right type.
That’s the core idea of Java generics: You tell it what type you want to use, and it takes care of the details.
In general, you can treat generics as if they are any other type—they just happen to have type parameters. But as you’ll see, you can use generics just by naming them along with their type
argument list.

A tuple library

One of the things you often want to do is return multiple objects from a method call. The return statement only allows you to specify a single object, so the answer is to create an
object that holds the multiple objects that you want to return. Of course, you can write a special class every time you encounter the situation, but with generics it’s possible to solve the problem once and save yourself the effort in the future. At the same time, you are ensuring compile-time type safety.

This concept is called a tuple, and it is simply a group of objects wrapped together into a single object. The recipient(接受者; 容器; 容纳者;) of the object is allowed to read the elements but not put new ones in. (This concept is also called a Data Transfer Object (or Messenger.)
Tuples can typically be any length, but each object in the tuple can be of a different type.However, we want to specify the type of each object and ensure that when the recipient reads
the value, they get the right type. To deal with the problem of multiple lengths, we create multiple different tuples. Here’s one that holds two objects:

//: net/mindview/util/TwoTuple.java
package net.mindview.util;

public class TwoTuple<A,B> {
  public final A first;
  public final B second;
  public TwoTuple(A a, B b) { first = a; second = b; }
  public String toString() {
    return "(" + first + ", " + second + ")";
  }
} ///:~

The constructor captures the object to be stored, and toString( ) is a convenience function to display the values in a list. Note that a tuple implicitly keeps its elements in order.

Upon first reading, you may think that this could violate common safety principles of Java programming. Shouldn’t first and second be private, and only accessed with methods named getFirst() and getSecond()? Consider the safety that you would get in that case:Clients could still read the objects and do whatever they want with them, but they could not assign first or second to anything else. The final declaration buys you the same safety, but the above form is shorter and simpler.
Another design observation is that you might want to allow a client programmer to point first or second to another object. However, it’s safer to leave it in the above form, and just force the user to create a new TwoTuple if they want one that has different elements.
The longer-length tuples can be created with inheritance. You can see that adding more type parameters is a simple matter:

//: net/mindview/util/ThreeTuple.java
package net.mindview.util;

public class ThreeTuple<A,B,C> extends TwoTuple<A,B> {
  public final C third;
  public ThreeTuple(A a, B b, C c) {
    super(a, b);
    third = c;
  }
  public String toString() {
    return "(" + first + ", " + second + ", " + third +")";
  }
} ///:~

//: net/mindview/util/FourTuple.java
package net.mindview.util;

public class FourTuple<A,B,C,D> extends ThreeTuple<A,B,C> {
  public final D fourth;
  public FourTuple(A a, B b, C c, D d) {
    super(a, b, c);
    fourth = d;
  }
  public String toString() {
    return "(" + first + ", " + second + ", " +
      third + ", " + fourth + ")";
  }
} ///:~

//: net/mindview/util/FiveTuple.java
package net.mindview.util;

public class FiveTuple<A,B,C,D,E>
extends FourTuple<A,B,C,D> {
  public final E fifth;
  public FiveTuple(A a, B b, C c, D d, E e) {
    super(a, b, c, d);
    fifth = e;
  }
  public String toString() {
    return "(" + first + ", " + second + ", " +
      third + ", " + fourth + ", " + fifth + ")";
  }
} ///:~

To use a tuple, you simply define the appropriate-length tuple as the return value for your function, and then create and return it in your return statement: