Object oriented programming with Java generics. In this module, we're going to learn what what generics are and why they're needed, how we declare generics. And it's not just saying list of cars. We may need more specificity than that as well. We'll see so we're going to learn how to use wildcards, how it works with sub-types and super-types. We're going to see how generics are used not just in type declarations but in methods declarations. And finally, we're going to learn about and there's that term generic or race, which actually is in the specification for this purpose. But we're going to see that it's really about what happened. At runtime because here's a secret. There are no generics outside of the compiler. So we're going to learn about that. So first off, what are generics? So here's this fancy term generics allow abstraction over types. Again, think of that as a fancy way of saying we can write generic code with without losing type safety. Generics are going to provide us a way to declare the types of objects that are used in some context used by generic code, such as a container, such as a collection, a list, a map, we want to be able to write generic code. Code but without losing type safety, and that's a big issue. So we're going to use compile-time type checking, which will help us to avoid runtime typecasting, both exceptions and the need to do it at all. Because this will help us reduce and almost eliminate the need to downcast now it is widely used in the collection framework, which is what drove this in the first place. But first let's go take a look and work into this. So here is our vehicle app. And here is a method that we might consider writing. Given an object array called racecars, hey, let's race. So for each object and race cars, let's go ahead and race or there's a problem. There is no race on object, that's the wrong type. So let's go ahead and fix that. Let's go ahead and change this to sports car. Each sportscar in the array. Well, now, we've got a different problem. Now, we're being told that racecars, there's a mismatch of type. Racecars is an array of object and we're trying to get sportscar out of it, and their system simply can't handle that automatically. So we're going to delete this code because it's useless to us and look at the next approach. So looping over each object, look and see if it is a sports car, because Hey, it could be a bank account. How do I know? I know, right?. I mean, it's just an object array. So if it's a race car, we'll do the downcast it's safe because we've done the instance of check. And now we can say race. So at some point you think this is silly. Why don't I just tell you that? It's a ray of SportsCar? Well, that would be ideal. That would be great. Here SportsCar now we can just loop over and make it work. Why don't we do that? I told you this was initially driven by the needs of the collection classes, so let's look at if instead of using an array, we use a collection class, that would be the next major module that we come to but we talked about generics first, because starting in Java five, the collection classes were rewritten to use generics. And so although there is a little bit of a chicken and egg problem we covered generics first with just some light coverage of collection. And then we'll go into much more deep look at collections having already covered generics. Let's just say I want a collection well, the problem is I'm back to the same problem collection is of object. And so I'm looping over objects and having to do the same thing with the instance of the race car. And even though you might have only put sports cars into the collection the compiler has no way of knowing that, and no way of asserting any sort of type checking and enforcing type safety. So here's where generics come in. Let me now use the syntax and specify that this is only a collection of sports car. So in angle brackets I put the type that's going to be allowed in here. Okay, so there's my sports car. So now I can get rid of all this other code that I no longer need. We're going to change this to sports car because that's what it is. And I don't need to do the type checking and I don't need to do the casting. And I can just refer to racecar and we're good. So now, I can do with collections what I could have done with a typed array. The collection itself is now typed. Now we're going to take that idea where we used it with collections and extend it anywhere we want in Java. That's what we're going to learn about in this unit on generics, how to write generic code. And the collection classes are the poster child for generic code. So here's what we've done. We've gone from an object array, to wanting it to be a typesafe array of just sports cars to a collection of objects to a collection of sports car using the generics Syntex. Now, when I pass a collection to race, it can enforce that has to be a collection. Only a sports car. You won't be able to put anything but a sports car into it. And when you go to get things out of the collection, we know they are sports cars, and therefore we can. Mediately race just discussed this was originally driven by the needs of the collection framework. Up until Java five in generics. We only had collection of objects and we had to cast things when we got them out how we had to make sure that they were what we expected, or we would get a class cast exception. Here we're seeing the ability to be typesafe. This is a list of string initialized to an ArrayList of string. In fact, we'll show you that there's a new syntax, we can use what they call the diamond operator with empty angle brackets means it has to infer the type from context. We can add things in but more to the point when I try to add something in, that's not a string that will be caught as an error. And when I get something out of the collection, there's no need to downcast it from object or even type check it from object because the only thing that could be in there is a string. So that's what generics are and why we care. And we'll spend the rest of this module learning more about that.
