Generic Classes and Formal Type Parameters

Generic code is usually written once and then used with many different types. Imagine you want to create groups of GUI components. Rather than writing one class for a group of buttons, another for a group of sliders, and so on, you can write a single generic class named ControlGroup. Its type parameter stands for the kind of component held in a group. The same class definition can then serve many purposes, and the only thing that changes from one use to the next is the type parameter.

This article follows one idea through the material: the type parameter is a placeholder that a caller fills in, and the author of the generic class decides what kinds of values may fill it. Keep that question in mind as you read. Who decides which types are allowed, and where is that decision written down?

The source describes a generic class that can represent a group of a chosen GUI component type. Two parameterized types come from the same definition: ControlGroup<JButton>, which represents a group of JButton objects, and ControlGroup<JSlider>, which represents a group of JSlider objects. The class definition is not copied or rewritten for each case. The formal type parameter inside the class is replaced by the actual type the caller supplies.

Read the diagram as a substitution. The definition still says ControlGroup<T>. When the caller writes ControlGroup<JButton>, every place where the class refers to T now refers to JButton. When the caller writes ControlGroup<JSlider>, the same places refer to JSlider instead. The class itself does not change; only the type that fills the placeholder changes.

Wildcard types are one tool for writing generic code. A wildcard lets a method work with collections of objects of various types, instead of being tied to a single element type. The method is written so that its parameter can refer to a collection whose element type varies, and the method body therefore does not depend on one specific element type. This is valuable when the same operation should apply to a list of strings, a list of numbers, or a list of components.

The source is explicit about the limitation. A wildcard does not restrict the types that are allowed as formal type parameters in a generic class or method definition. A wildcard can make a method more general, but it cannot tell the compiler that the type parameter must come from some particular family of types. A wildcard alone cannot provide that kind of restriction, and this is the gap that bounded types were introduced to fill.

The source frames the difference as a matter of responsibility. The author of a generic class decides what the class is meant to hold. A wildcard lets the author describe a method that is flexible about element types. A bounded type lets the author state that a type parameter may only be filled with types that satisfy the stated restriction. Because the restriction belongs to the definition itself, every use of the class is held to it.

The comparison shows the key point of this article. A wildcard operates on the method's parameter and makes that parameter flexible. Only a bound declared on the type parameter, in the class or method definition, can restrict which types may be supplied as the formal type parameter.

The source gives a hypothetical extension of the ControlGroup scenario to show the purpose of a bound. Suppose the author only wanted ControlGroup to hold components that can be placed on a screen as interactive controls. A wildcard would not express that requirement. A bounded type exists to state a restriction of exactly this kind on the type parameter in the class definition. The example is hypothetical; its role is to show what a restriction does, not to define a real Swing hierarchy.

Trace the hypothetical bound through the same substitution you saw earlier. ControlGroup<JButton> and ControlGroup<JSlider> are both admitted, because each type satisfies the restriction written in the definition. A supply such as String would not satisfy it, so the restriction rejects that use. The rejection comes from the definition, not from anything the caller chose to do in the method that receives the group.