Generics: Lesson

As of now, our generic classes, interfaces, and methods have all taken a single parameter type. But what if our program needed to specify two or more parameter types? Java generics allow us to do that as well. Let's look at an example:
```java 
public class Box<T, S> {
  private T item1;
  private S item2;
  // Constructors, getters, and setters
}
Box<String, Integer> wordAndIntegerBox = new Box<>("Hello", 5);
```
In the example above, we created a generic class `Box` with two type parameters, `T` and `S`, by providing a comma-separated list of type parameters in the diamond operator. We also instantiated a `Box` reference named `wordAndIntegerBox` by providing the necessary type arguments in a comma-separated list: `<String, Integer>`.

This can also be done for interfaces and methods. Let's look at an example for a method:

```java 
public class Util {
  public static <T, S> boolean areNumbers(T item1, S item2) {
    return item1 instanceof Number && item2 instanceof Number; 
  }
}
  
boolean areNums = Util.areNumbers("Hello", 34);  // false
```
In the example above, we created a `static` `areNumbers()` method that has two generic type parameters: `T` and `S`. Note that a comma-separated list of type parameters, `<T, S>`, must be specified in the method signature before the return type. A cool thing about the example is if it weren't for Java's type inferences, the above method would have to be called like this:
```java
Boolean areNums = Util.<String, Integer>areNumbers("Hello", 34);  // false
```
In the example above, we explicitly specified the type arguments `<String, Integer>` before the method name. Type inferences will infer these types from the arguments passed in, `"Hello"` and `34`, making the explicit arguments unnecessary. 

Let's practice creating a multiple-type parameter class.


Multiple Type Parameters

We've covered generic classes and interfaces, but what can we do if we want one of our methods to be generic and not the whole class or interface? We can create generic methods to do just that. For example:
```java
public class StringBox {
  private String data;

  public <T> boolean isString(T item) {
    return item instanceof String; 
  }
}

StringBox box = new StringBox();
box.isString(5); // Returns false
```
In the example above, using the class `StringBox`, we created the generic method `isString()` with a generic type `T` as a method parameter. It's important to note that generic methods need to include the type parameter, `<T>` in our example, before the return type, even if the return type is `void`. The generic method is called like any other method as shown. 

We can also do this with `static` methods. Their signatures have the same requirements except for also needing the `static` keyword. For example:
```java
public class StringBox {
  private String data;

  public static <T> boolean isString(T item) {
    return item instanceof String; 
  }
}
StringBox.isString(5);  // Returns false
```
In the example above, we see how we made the `isString()` a `static` method by adding `static` to the method signature. We call it by using the class name instead of an object. 

Let's practice creating generic methods.


Methods

We've seen how to create a generic class, but we can also create a generic interface. Let's look at an example:
```java
public interface Replacer<T> {
  void replace(T data);
}
```
The generic interface `Replacer` is created like a generic class where the type parameter `<T>` must be appended to the interface name. Interface method declarations are similar to non-generic interfaces and can include non-generic methods as well.  

A generic interface can be implemented by a generic class and its generic type parameter can be used as the argument to the interface type parameter. For example, let's have our `Box` generic class implement the interface `Replacer`:
```java
public class Box <T> implements Replacer<T> {
  private T data;
  
  @Override
  void replace(T data) {
    this.data = data; 
  }
}
``` 
In the example above, the `Box` type parameter `<T>` will be used as the type argument for the `Replacer` type parameter `<T>`. 

We can also have a non-generic class implement a generic interface by specifying the type argument to the interface. For example:
```java
public class StringBag implements Replacer<String> {
  private String data;
  
  @Override
  void replace(String data) {
    this.data = data; 
  }
}
``` 
In the example above, the `StringBag` is a non-generic `class` that implements `Replacer` and provides `String` as the argument to the type parameter. Notice that the `replace()` parameter `data` has a `String` type as opposed to the generic `T` in the previous example. 

Now let's create `interface` type references similarly to how we created generic `class` references: 
```java
Replacer<Integer> boxReplacer = new Box<>();  // Using generic `Box` implementation
Replacer<String> bagReplacer = new StringBag();  // Using non-generic `StringBag` implementation
```
In the example above we created two `Replacer` references. The `Box` implementation can be of any type but the `StringBag` implementation needs to be a `<String>` type because of the non-generic class implementation. 

Let's practice creating generic interfaces and references. 


Interfaces

Previously, we saw how generics can help make our code more manageable and flexible for future needs. We created the following generic class:
```java
public class Box <T> {
  private T data;

  public Box(T data) {
    this.data = data; 
  }

  public T getData() {
    return this.data;
  }  
}
```
In the example above, notice that: 
- The type parameter must be specified within the diamond operator (`<>`) after the `class` name. 
- The type parameter, `T`, is similar to a method parameter but instead receives a `class` or `interface` type as an argument as opposed to a reference or primitive type.  
- The constructor accepts a `T`-type parameter to initialize `data`.
- The getter method returns the type parameter `T` when returning `data`.

Creating generic classes is great, but we also need to be able to create instantiations of them in our programs:
```java
Box<String> myStringBox = new Box<>("Apple");
```
In the example above, the object `myStringBox` is created like a non-generic object, but differs in:
- Needing the diamond operator with the `class` or `interface`  type argument, `<String>` in this example, after the `class` name.
- Needing the empty diamond operator before calling the constructor `new Box<>("Apple")`. 

When defining type parameters, although not being a hard requirement, it's best practice to make them single, uppercase letters to easily distinguish them from the names of classes or variables. By convention, type parameters are `E` (Elements), `K` (Key), `N` (Number), `T` (Type), `V` (Value), and `S` (or `U` or `V`) for multiple type parameters.  

One last thing to note is that before Java 7, generic references had to be created like this:
```java
Box<String> myStringBox = new Box<String>("Apple");
```
In the example above, the `<String>` type argument also needed to be specified prior to calling the constructor. This is no longer necessary due to Java's _type inference_ where the compiler can infer the `<String>` type argument in the constructor from the context of the reference definition `Box<String>`. 

Let's practice creating a generic class and creating an instance of it.


Classes

a factory grouping pieces of clothing into containers

When using Java, we often write classes and algorithms that work around certain data types. Let's look at the following `class` as an example:
```java
public class StringBox {
  public String myString;
} 
```
In the example above, we have a `StringBox` class which represents a real-world box of words. This class's methods perform all of their computations with regards to the `String myString` field. What if we wanted a box of `int`s? We could create a new class:
```java
public class IntegerBox {
  public int myInt;	
} 
```
The example above meets our requirements, but as the program grows and we need more types of boxes, it will become unmanageable. We can solve this problem by using _generics_.

Generics, like the name implies, allow us to create generic classes and methods by specifying a type parameter. We can make `StringBox` and `IntegerBox` into a generic `Box` class like so:
```java
public class Box<T> {
  private T data;
}
```
In the example above, we created a generic `Box` class with a type parameter `T`. All class methods perform their computation around the `T`-type parameter We can now specify that we want a `String`, `Integer`, or any other type of `Box` by specifying a type argument.

In the example above, we created a generic `Box` class with a type parameter `T`. All class methods perform their computation around the `T`-type parameter

Over the course of this lesson, we'll continue learning about generics in Java and their use cases.


Introduction

Recall that generic code can have an upper bound when defined using a type parameter or a wildcard. We can also provide a _lower bound_ when working with wildcards. A lower bound wildcard restricts the wildcard to a class or interface and any of its parent types. For example:
```java
public class Util {
  public static void getBag(Bag<? super Integer> bag) {
    return bag;
  }
}
```
In the example above, we used the `super` keyword to restrict the argument to `getBag()` to be a `Bag` of `Integer`, `Number`, or `Object`. If a call to `getBag()` with `Bag<Double>` is made, it would result in an error because `Double` is not an `Integer` or one of its parents. 

Some important things to note about lower bounds are:
- They cannot be used with generic type parameters, only wildcards.
- A wildcard cannot have both a lower bound and an upper bound. In this case, it's best to use a generic type parameter.

There are some general guidelines provided by Java as to when to use what type of wildcard:
- An upper bound wildcard should be used when the variable is being used to serve some type of data to our code.
- A lower bound wildcard should be used when the variable is receiving data and holding it for later use.
- When a variable that serves data is used and only uses `Object` methods, an unbounded wildcard is preferred.
- When a variable needs to serve data and store data for later use, a wildcard should not be used (use a type parameter instead).

Let's practice adding a lower bound to a generic method.


Wildcard Lower Bounds

We've seen how generics make our code scalable by allowing us to provide type arguments to classes, interfaces, and methods. What if we needed to restrict what class or interface could be used as a type argument? We can accomplish this by assigning an _upper bound_. An upper bound will restrict a generic type to be a specific type or any type that `extends` it. Let's see how this is done:
```java
public class Box <T extends Number> {
  private T data; 
}
```
In the example above, we defined a type parameter `T` and added an upper bound type `Number` for `T` with `extends Number`. The `extends` in this example means that `T` can be a `Number` or any of its subclasses (or interfaces). 

We can create references to `Box` as follows:
```java

Box<Integer> intBox = new Box<>(2);  // Valid type argument
Box<Double> doubleBox = new Box<>(2.5);  // Valid type argument
Box<String> stringBox = new Box<>("hello");  // Error
```
In the example above we:
- Created two `Box` references with type arguments `Integer` and `Double`, which are both child classes of `Number`.
- Attempted to create a `Box` reference with type argument `String` and received an error because `String` is not a `Number` nor is it a subclass of `Number`. 

We can also add upper bounds to generic methods as follows:
```java
public static <T extends Number> boolean isZero(T data) {
  return data.equals(0);
}
```
In the example above, it's important to note that we added the `Number` upper bound before the return type. 

Java also allows us to create a type parameter with multiple bounds. Let's look at an example:
```java
public class Box <T extends Number & Comparable<T>> {
  private T data; 
}
```
In the example above, we specified multiple bounds (`Number` and [`Comparable`](https://www.codecademy.com/resources/docs/java/comparable?page_ref=catalog)) for type parameter `T` using the `&` operator between the different upper bounds. It's important to note that when defining multiple bounds, any upper bound that is a `class` (in our example `Number`) must come first followed by any interfaces (in our example `Comparable<T>`). 

Let's practice adding an upper bound to a generic class. 


Upper Bounds

We've seen that generic code can take type arguments to help generalize our code. We can make our code even more general when we don't need the more strict type checking of using type parameters by using _wildcards_. A wildcard, denoted by the `?` symbol, represents an unknown type when used with generic methods. Let's look at an example:
```java 
public class Util {
  public static void printBag(Bag<?> bag) {
    System.out.println(bag.toString()); 
  }
}
Bag<String> myBag1 = new Bag("Hello");
Bag<Integer> myBag2 = new Bag(23);
Util.printBag(myBag1);  // Hello
Util.printBag(myBag2);  // 23
```

In the example above, we defined a `static` generic method that works on `Bag` types. We specify that `Bag`, which is a generic class, can be of any type by using the wildcard `Bag<?>`. We also created two `Bag` references of different types, `String` and `Integer`, and used them as arguments to `printBag()`. 

You may be thinking how this is different than using a type parameter because we could write the above method as:
```java
public static <T> void printBag(Bag<T> bag) {
  System.out.println(bag.toString()); 
}
```
In the example above, we've defined the parameter as `Bag<T>` as opposed to `Bag<?>`. This implementation makes no difference, but you may notice that the wildcard version is better as it does not need the extra `<T>` before the return type making the signature easier to read. 

In general, we should use type parameters, when we have a relationship between the type of arguments and the return type. For example:
```java
public static <T> Bag<T> getBag(Bag<T> bag) {
  return bag;
}
```
In the example above, we created a method that accepts a `Bag` of some type `T` and returns a `Bag` of the same type `T`. This use of type parameters maintains strong type checking throughout our code. 

We can also create upper bounds and lower bounds (we'll see this later) when using wildcards. For example:
```java
public static void printBag(Bag<? extends Number> bag) {
  System.out.println(bag.toString()); 
}
```
In the example above, `printBag()` accepts any `Bag` that is a `Number` and will produce an error when passing a type of `Bag` that does not extend `Number`. For example, `Bag<String>` will produce an error.  

Let’s practice using wildcards in our generic code. 

Wildcards

Great job learning about generics! In this lesson we've covered how:
- Generics help us make generic, scalable code.
- The diamond operator (`<>`) is used to define generic classes, interfaces, or methods.
- Generics provide compile-time type safety and bug detection as opposed to raw types.
- We can create multiple bound generic classes, interfaces, and methods.
- Wildcards are used to define unknown types.
- To Add upper bounds to type parameters and wildcards.
- To Add lower bounds to wildcards.

Knowing these topics will help you create scalable, type safe code, and give you a better understanding of the Java collections framework (we’ll learn about this later).


Review

Generics allow our programs to adapt to different data type needs but one issue with them is that we cannot use primitive types (`int`, `double`, `boolean`, etc) as arguments to generic type parameters. For example, we cannot create a `Box` of integers this way:
```java 
Box<int> intBox = new Box<>(56);
```
Fortunately, Java provides _wrapper classes_ to allow us to create objects of primitive types and use them as type parameters. We can now create a `Box` of integers this way:
```java 
Box<Integer> intBox = new Box<>(56);
```
In the example above, the `Integer` wrapper class is used in place of `int` to work as a type argument. Also, notice that we are able to pass `56` as the argument to the constructor and this is because of _autoboxing_. 

Autoboxing allows wrapper classes to take primitive values and convert them to their corresponding wrapper object by automatically calling the `valueOf()` method. For example, the following statements are equivalent when creating a `Box<Integer>`:
```java
Integer a = 56;  // Autoboxing, automatic call to `valueOf()`
Box<Integer> intBox1 = new Box<>(a);
Box<Integer> intBox2 = new Box<>(56);  // Autoboxing, automatic call to `valueOf()`
Box<Integer> intBox3 = new Box<>(Integer.valueOf(56));
```

We can also take the wrapper object and convert it back to its primitive value using one of the wrapper object's `Value()` methods. This process is also automated for us and is known as _unboxing_.  For example:
```java
Integer a = 56;
int aPrimitive1 = a.intValue();  // Return primitive `int` value from `Integer` object
int aPrimitive2 = a;  // Unboxing, automatic call to `intValue()`
```

a table of primitive data types and their corresponding wrapper classes

Wrapper Classes

We've done great work learning about generic classes, interfaces, and methods. Let's discuss some benefits of using generics besides making our code more scalable. We can get away with not providing a type argument to a generic class or interface. This is known as using a _raw type_ and they were prevalent before the introduction of generics in Java 5. For example:
```java
public class Box <T> {
  private T data;

  public Box(T data) {
    this.data = data; 
  }

  public T getData() {
    return this.data;
  }  
}

Box box = new Box<>("My String");  // Raw type box
String s2 = (String) box.getData();  // No incompatible type error
String s1 = box.getData();  // Incompatible type error
```
In the example above:
- Using the generic class `Box`, we created a raw type `Box` and passed `"My String"` as an argument.  
- We called `getData()` and typecast the result in `String s2`. This has no error because we are explicitly downcasting to `String`.
- We called `getData()` to store the result in `String s1`. We get an `Incompatible type` error as `getData()` returns an `Object` type and we are trying to implicitly downcast to a `String`. 

Raw types should be avoided because generics:
- Avoid "incompatible type" errors when retrieving data from raw types. 
- Avoid a potential runtime `ClassCastException` error when explicitly typecasting.
- Give us compile-time type checking, which helps detect bugs before our code runs. 
- Help when the JVM applies _type erasure_

When using generics, type erasure is applied by the JVM and will cause all type parameters to be replaced by `Object` or their type bounds (we'll learn about this later). The type erasure will also apply any necessary type casting to ensure our code is type-safe and that the final byte code produced has non-generic types. 

Great job learning about generics so far!
