Records
A few years ago, I was having a discussion with some higher education professors about the right time to introduce records in their CS1 Java course. Some of them were resistant to doing this, as they were used to teaching students to write classes for every new object that was needed. They liked that they could have their students create really simple classes that represent data and only have accessor and mutator methods. It allowed them to have an early introduction to the structure of a class. They were using it as an instruction strategy.
For example, one assignment might have students write a class to represent a point. The point would have:
- an
x value
- a
y value
- a constructor
- accessor methods
- mutator methods
Why is it poor design to have a mutator method in a Point class?
Well, let's think about math class. When we teach students to transform points, we don't give the transformed point the same name. We might say that A' is the reflection of A. But we recognize that this isn't the same point. The point A didn't stop existing. We are just referencing a NEW point. So, actually, if you wanted to write transformation, you should be returning a point, not changing it to a new point. But this wasn't how I was thinking of it when I was a teacher nor how I was teaching my students to write the Point class.
Fast forward to Java 16 and say hello to records. Records have been designed to treat data as data. Data that is immutable, needs to be protected. This doesn't mean you can't write a method to translate the point to a new location, but you do need to recognize that it is now a new point.
I completely sympathize with the instructor's desire to provide students with practice writing classes and all the methods from the ground up, and wanting to use classes as an instructional strategy. But, at the same time, are you teaching students a misunderstanding about design and what can and should be done with data if you only teach your students how to use the tool of creating classes? It's just as important for students to understand which tool to use, as it is to understand how to write code using those tools.
This isn't a case of having students write code the hard way before showing them the "short-cut". Using records is not a "short-cut" at all. It is actually the right tool for the job. Because data is immutable, records allow us to leverage the compiler to infer some standard methods and constructors that will be required. What this actually does, is prevents mistakes programmers might make by having to write the constructor and methods themselves. It actually keeps the data safer, by having a prescribed way of handling the access to this data.
So, how do records work?
Below is an example of how we can create a record to store data from an excel document. You will want to provide a variable for each column. Because, we wouldn’t want the values of this data to be modified, so a record is the right tool for the job.
For example, say you want to analyze data about fruit prices. The excel document has a list of fruits and their retail prices. The following columns are in the spreadsheet:
- Fruit,
- Form (fresh, canned, frozen, juiced, dried),
- Retail Price,
- Retail Price Unit,
- Yield (percentage of usage fruit),
- Cup Equivalent Size,
- Cup Equivalent Unit, and
- Cup Equivalent Price (The 1-cup equivalent equals the weight of enough edible food to fill a measuring cup).
Create a record to represent this data as follows:
record Fruit (String type, String form, double retailPrice, String retailPriceUnit,
double usableYield, double cupEquivSize, String cupEquivUnit,
double cupEquivPrice) {}
This provides us with the following:
A constructor
public Fruit (String type, String form, double retailPrice, String retailPriceUnit,
double usableYield, double cupEquivSize, String cupEquivUnit,
double cupEquivPrice)
Private Instance variables
- String type
- String form
- double retailPrice
- String retailPriceUnit
- double usableYield
- double cupEquivSize
- String cupEquivUnit
- double cupEquivPrice
Accessor methods
- String type();
- String form();
- double retailPrice();
- String retailPriceUnit();
- double useableYield();
- double cupEquivSize();
- String cupEquivUnit();
- double cupEquivPrice();
Additional methods
- equals
- toString
- hashCode
Resources
Want to learn more about Data-Oriented Programming? Check out this series of articles from one of my colleagues Nicolai Parlog.