السجلات (Records) كمعاينة: مساواة مجانية

Written Explanation

One line instead of fifty

A record declares a data carrier by listing its components in the header:

record Money(long cents, String currency) { }

The compiler generates, from those components:

• a private final field for each component;
• a constructor taking all the components (new Money(100, "SAR"));
• an accessor method for each component, named like the component: m.cents() and m.currency() (no get prefix);
• equals, hashCode, and toString.

All fields are final, so a record is immutable: there are no setters, and you cannot reassign a field after creation. That is the same immutability idea from the encapsulation module, built into the language.

What the generated methods do

The Java documentation for java.lang.Record states the rules:

• equals is true when the other object is of the same record class and each component is equal (object components compare with Objects.equals).
• hashCode combines the hash codes of all components, and two records made from the same component values must have the same hash code.
• toString contains the record's class name, each component's name, and each value, for example Money[cents=100, currency=SAR]. The documentation says the exact format may change, so do not parse it.

So the contract from Lesson 3 holds automatically: equal records have equal hash codes, because both come from the same components. It also holds in the sense of Lesson 4: the text is readable out of the box.

Records are not a free pass

Three things to keep in mind:

1. All components count. Record equality compares every component. If you want equality by an id only (as with Customer(id, name) in Lesson 3), a plain record does not match: two records with the same id and different names are unequal. For that you would write a normal class (or override equals inside the record, which is beyond this preview).
2. toString shows every component, including secrets. A record Login(String user, String password) would print the password! You can override toString inside the record, but you must remember to.
3. Shallow immutability. A component that refers to a mutable object (such as a list) can still change inside it; the reference is final, the contents may not be.

Comparing with the Lesson 3 recipe

The generated methods follow the same recipe you used by hand: equality compares the fields, the hash code combines the same fields, and the text lists them. The difference is who writes it. A hand-written pair can drift (someone adds a field to equals and forgets hashCode), while the compiler regenerates the record's methods from the header every time. The header is the single source of truth, so adding a component updates all three methods at once.

A record can still contain methods, so a small value type can keep its own helper such as isZero(). Details of that, and of validating values in a record's constructor, come later.

Where records fit

Use a record when the type is "just data" and every component is part of its identity: money, coordinates, a date range, a response object. Use a normal class when the object has behavior and changing state (an Account with a balance), or when equality is by id only. You will see records again in later modules on data transfer and validation; this lesson only shows that they remove the boilerplate that Lesson 3 asked you to write.