If we think about a set of vehicles, say a car, a bus and a plane. The car and bus may implement an interface called road vehicle. We define the interface in classes to these. We may wish to have a data structure that can park specific vehicles. To do this, we define a generic class on line 27 by adding a tape to the Garage class. Inside the class, we define an array of the type, and set it to an empty one. The class also has a function called Park, which takes a vehicle of type T, and we push this to the vehicles array. Remember that in our TypeScript code, if the item we tried to push to the array is not the type specified, when we created an instance of the Garage class, we'll get an error from the compiler. We also shouldn't try and access any type of specific properties like speed, as at the moment this property will not exist on every type, and this could cause errors, as shown on line 33. So, we can now create instances of the Garage class that may specify the type that it can work with. We've created instances of the car person plane, and an instance of the Garage with no type specified. These are runs lines 37 to 40. If we call park on my Garage with each of our vehicles, lines 42 to 44. This is all good with no errors, as there is no tape associated with my Garage. However, when we create an instance of Garage and specify the car as the generic type, as a line 46, this behavior changes. Now, when we try to park each of the vehicles in my Garage, we're allowed to park a car, and perhaps surprisingly a bus, until we remember that a bus looks like a car programmatically anyway, because it implements this Same interface and has the same properties. The plane may creates an error that doesn't look like a car, programmatically or otherwise. The Garage classes a generic class, as it can work with specified classes as it's created. Just to note, generic classes are only generic on their instant side. So you can't use static properties, as these don't require an instance of the class to be created to be accessed. So what if we wanted to ensure that the Garage could accept any vehicle that implements the road vehicle interface? Well, we can constrain the generic by specifying that team must extend an interface type or a class. In fact, we could use multiple extensions using a comma to separate them to be even more specific. You can see that we've created another generic class. This time it's called road vehicle Garage. It's on line 53. The generic type of this T, now most extendable road Vehicle interface we created earlier. So now as long as the class we want to work with the road vehicle Garage implements the road vehicle interface, it will be accepted into the Garage. That will be the case even if we lose the generic definition on the instantiation in the class. We do this on line 63. And then you can see that if we park a car or a bus that's fine, but it's not okay to park a plane like it was before. It doesn't implement road vehicle. We also create a car road vehicle Garage which is okay as car implements vehicle. But if we try and pass in plain as the type it fails. This constraining of the generic type can be done anywhere T is used.