الهوية مقابل المساواة

Written Explanation

Two questions

For primitives such as int and double, == compares the values: 5 == 5 is true. For object references, == compares the references: it is true when both sides point at the same object (or both are null). It never looks inside the objects.

The default equals is identity

From Lesson 1: Object.equals returns true only for the same object. So for a class that does not override it:

Account x = new Account("A-1");
Account y = new Account("A-1");
Account z = x;
System.out.println(x == y);       // false: two objects
System.out.println(x.equals(y));  // false: default equals is identity
System.out.println(x == z);       // true: same object
System.out.println(x.equals(z));  // true

z is not a copy: it is a second name for the same object, like two people holding the same note.

String overrides equals

The String class overrides equals to compare the characters. So a.equals(b) is true when both strings have the same text. That is the correct way to compare text. == on two strings still asks the identity question, and the answer depends on how each string was created.

Why == sometimes works on strings

The Java Language Specification says that string literals (and compile-time constant expressions) with the same text refer to the same String object: they are interned. So:

String a = "bank";
String b = "bank";
System.out.println(a == b);       // true: both literals share one object

But a string built at run time is a new object:

String c = new String("bank");
String suffix = "ank";
String d = "b" + suffix;          // built at run time: suffix is a variable
System.out.println(a == c);       // false
System.out.println(a == d);       // false
System.out.println(a.equals(c));  // true
System.out.println(a.equals(d));  // true

This is why == is dangerous: it appears to work in a quick test with literals and then fails when the text comes from a file, a network request, or a user typing. The rule is simple: never use == to compare the content of strings. (== on strings is legitimate only when you really mean identity, which is almost never.)

The null-safe comparison

If command could be null, then command.equals("quit") throws NullPointerException. Put the literal first:

if ("quit".equals(command)) { ... }   // false when command is null, no exception

A literal is never null, so the call is always safe. The java.util.Objects.equals(a, b) helper does the same for two variables: it returns true if both are null, false if only one is, and otherwise a.equals(b).

Why identity still matters

Identity is not a lesser tool. Two variables that point at the same object are aliases: a change made through one is visible through the other, because there is only one object. Asking x == z is how you check whether two variables are aliases, which is sometimes exactly the question (for example, "am I about to compare an object with itself?"). That is why equals implementations begin with if (this == o) return true;: it is a fast and correct shortcut, since an object is always equal to itself.

A quick checklist before you compare

1. Are both sides primitives? Use ==.
2. Are they objects that represent values (strings, money, dates)? Use equals, with the known value on the left if the other side may be null.
3. Do you genuinely mean "the same object"? Then == is right, and it is worth a comment saying so.

Choosing identity or equality for your own class

• Entities with a life of their own (an open database connection, a thread, a specific bank account object being modified): identity may be right.
• Values (money, a date, a coordinate, an email address): two objects with the same data are interchangeable, so equality should compare the data. You do that by overriding equals, which Lesson 3 teaches.