Records & Wrapper Classes

[00:00:00]
>> So, let's talk about records. They are a newer type of construct in Java. They are also a Java class, but they are made for very simple things where you basically have some fields and maybe a method or two, maybe none, right? So, these are typically called POJOs in Java.

[00:00:27]
You might hear somebody say POJO. POJO stands for Plain Old Java Object. And Plain Old Java Objects usually have some fields, some getters and setters, nothing else really, okay? And you use these a lot to model different things, different types of objects. And so, records were created to kind of help with that.

[00:00:50]
Cuz, there's so much boilerplate code to write those getters and setters all the time. Instead, we can write record instead of the word class, as we see on line one. So, you would say the access modifier, in this case it's public, record, as opposed to class, and then the name of the record.

[00:01:08]
So, this is a count. Also, something that you don't see with regular classes is the set of parentheses, almost like a constructor. The set of parentheses right after the declaration of the record, and then you would just list a comma delimited list of the fields for that record.

[00:01:29]
That's it, I don't have to write anything else. With this automatically in the background, my getter methods are created and all of that sort of stuff. So, I could use that and it's really great for modeling different types of objects and stuff. Now, if you just wanted to add methods to this you can.

[00:01:53]
And so, to do so, notice, put these little curly braces, and you're done. If you want a method, you would expand those curly braces and then add any methods that you wanted to inside of the curly braces. As far as working with records, you instantiate them just like you would any other class.

[00:02:16]
So, this is an account. I am calling new Account. And I'm calling a constructor even though there is no constructor defined in record, right? But, we did say this is the data that has to come with it, so you would have to pass in that data. I don't know if record has, record does not have a default constructor like that.

[00:02:39]
I'm glad I mentioned that. So, and this is the case for classes 2. If you define a constructor yourself, it doesn't have to be a default one. So, we talked about the all arg, I showed you that you don't have to use all the args. You can do whatever you want.

[00:03:02]
So, you could have had a rectangle that only takes a length as a constructor. A rectangle that only takes the width, you do whatever you wanna do. But, if you do explicitly define a constructor, then that default constructor is not automatically created for you anymore. That's wiped away, right?

[00:03:24]
Even if you have not explicitly declared a default one, but you declared a different type, then that one no longer exists. Now for records, you're kinda creating a constructor here if you think about it, this is like a class and a constructor declaration all in one. I'm saying public record and I'm saying here are all the fields.

[00:03:43]
Now, records are final. So, I told you that's one of the access modifiers, you don't have to explicitly say it here, because they are all final. By it being final, what that means is you cannot later change the field values. There are no setters. When I said this is my account and I gave it those numbers, that's it.

[00:04:10]
I can never change that. So you see on line 3 where I say account that setType. There are no setters. You cannot set the type, you cannot change anything. The fields are final. So, those values that I gave it in line 1, that's it, that's my one shot.

[00:04:30]
Now you can do getters on line 5. But, the getters do not start with get like they conventionally do in classes and records, you would call the field as a method name. So, this is account balance instead of account get balance, yes.
>> For this records type, is it a type or is it a.

[00:04:55]
>> Yeah, you can define it as a type.
>> Would you also need to do the boilerplate, for example, for a hash code or?
>> No.
>> Okay.
>> All of that's done for you. So all classes, and we'll talk about inheritance in a while, but all classes or all objects inherit from this one godfather class in Java called object itself.

[00:05:27]
So, object is god in Java, right? And everyone inherits from object. And so with that, object has some methods like hash code and equals and things like that. That typically you would maybe wanna override those with your own implementation. But in records, you do not have to override them all.

[00:05:47]
All that is kinda automatically done, yes.
>> When would this be an efficient method to use where you set everything originally?
>> Yeah, so this would be good when you just need to model something, I just wanna model this account. There's nothing else I wanna add to it other than getter methods for its fields, right?

[00:06:09]
I don't have anything else to add here. And so, this would be a good case to use as a record versus a class, cuz there's nothing more I wanna put. There's no other methods that I wanna add to it. I don't care about people. When you first set up your account, you don't then come and say, well, it's no longer as checking I want it to be a savings.

[00:06:30]
It's not a thing, right? You don't go and say, my account number, I don't want it to be this anymore, I want to be that. So, this makes sense for final. Once you set it up, that initial time, that's it. Now the balance might change, right? So, [LAUGH] all right.

[00:06:49]
>> I noticed you did put a balance after checking. So, would that mean that value would be hardcoded and that would not be manipulatable?
>> Right, so, it would not be manipulatable, but, you might have something that's updating records or something like that in a database, right? So, I might have a method in there that says update balance.

[00:07:15]
And then it'll go off to a database, it'll update the database and all of that stuff. It would not be reflected in this object itself. So maybe balance is not a great attribute to have on this record. You might wanna do a new object type that's called account balance or something that's more flexible.

[00:07:42]
>> And then the account balance might be owned by the account.
>> Yeah.
>> Okay, so records can have or cannot have message in them.
>> They can, you can add methods. None of them can change the values of any of the fields, but you can add methods, yeah.

[00:08:03]
And to do so, is like this online 7. So within those curly braces, I just added a method there.
>> So a good example for a record might be, for example, something like a tax rate where, unless it's changed 10 years down the line. Having a permanent value for that is not necessarily a bad thing if you're just referencing it once.

[00:08:28]
>> If it's bigger than just a value, right? Otherwise you would just make it a value into some field or something. But yeah, if it's an object with some behaviors, then yeah, sure.
>> Is that kind of meant to replace, I don't know POJO, or?
>> Yeah, so it's meant as, we're sick of writing POJOs, okay?

[00:08:49]
It's just so redundant, and it's all of this verbose boilerplate code. I write my feels. That's why IntelliJ made generate the getter and setter, so I don't have to write this. But back in the day, we were literally writing these getter and setter methods. And it's just, gosh, it's a bane to our existence, right?

[00:09:12]
And so records is a smarter way. How about you don't write any methods? What's the fields that you want? Specify those and we're good to go. So, this is a newer construct in Java, maybe like a year or two. And so you may not see them that much just yet.

[00:09:35]
People are still kind of getting used to them and stuff like that. But a lot of Java programmers were using things like Lombok. Dependencies and stuff that helped you manage POJOs a little bit better. But it's really good for back-end development where you're like deserializing, JSON from API responses and things like that.

[00:10:01]
You don't necessarily need to update anything. You just need a representation of that JSON in Java object form. Okay, all right, so wrapper classes someone asked the question what's the difference between int and integer with a capital I for example? So, all of the primitive data types can also be represented in object form.

[00:10:31]
So before we talked about objects, we were doing int, we were doing double, Boolean, and char, all of that stuff, which is perfectly fine. I still use all of that stuff. But if you needed that to be in the form of an object so that you can maybe access some convenience methods, you can represent it in that way.

[00:10:51]
So integer right here like this second line, it's pretty much exactly the same as the first line except now with the number two I can say number two dot, and I would have a list of methods I can use for this. So, here are the primitive data types, and here are the wrapper classes that correspond to them.

[00:11:13]
So, int, double, long, float, boolean, char, and byte. Literally, just with a capital letter, except for integers, always spelled out.
>> Is a string of wrapper class.
>> String is not a wrapper class. But string is an object. So string is not a primitive data type. We've used string, notice that it always started with a capital letter.

[00:11:35]
Well, maybe you didn't notice that, did you? Okay, so it is an object in and of itself.