الفئة Object

Written Explanation

Every class has a parent

In the inheritance module you wrote class SavingsAccount extends Account. What about Account itself? If you do not write extends, the compiler treats the class as if it said extends Object. So the family tree always ends at one root:

Object
  └── Account
        └── SavingsAccount

Java's own documentation says the same: Object is the root of the class hierarchy, and every class has it as a superclass. Because of inheritance, a SavingsAccount object has everything Account offers and everything Object offers.

That also means a variable of type Object can hold a reference to any object, because every object "is an" Object (the upcasting idea from BEG-023). This is why some general-purpose Java code is written in terms of Object.

The inherited methods

Here is what every object gets for free. The first four are the ones to know now.

Two details are worth noticing. First, getClass() is final, so no class can change it: the answer is always the real class of the object. Second, the thread-related methods exist on every object for historical reasons; you will not use them in this module.

The defaults are generic

Because Object knows nothing about your class, its methods can only be generic:

• The default toString() returns the class name, an @ sign, and the hash code in hexadecimal. The Java documentation notes the text is not guaranteed to be stable over time or between runs, so never rely on it.
• The default equals is identity: a.equals(b) is true only when a and b are the same object, exactly like a == b.
• The default hashCode() is tied to the object's identity too, and it is consistent with the default equals.

Think of the banknote: the default only recognizes "this exact note in my hand". It has no idea that two notes of 100 riyals are worth the same.

Which methods do you override?

Three of the inherited methods are overridden constantly:

1. toString() so that printing and logging show something readable.
2. equals(Object) so that two objects with the same value can count as equal.
3. hashCode() which must always be overridden together with equals (Lessons 3 and 6).

You override them only when they make sense. An Account that is a unique living entity might keep identity equality. A Money value should have value equality. Lesson 2 gives the tools to decide.

Why have a single root at all?

A common root gives the language one guaranteed minimum that every object supports. Library authors can write code such as "store this thing, print this thing, compare this thing" without knowing your class, because they can count on Object's methods being there. It also means the compiler can always answer "does this call make sense?" for the basic methods. The price is that the defaults must be cautious: they cannot assume anything about your fields.

A good habit when you meet a class for the first time is to ask three questions: what does it print as, what does it consider equal, and what hash does it give? If the answers are the Object defaults, then printing shows Name@hex, equality is identity, and the hash follows identity. That is perfectly acceptable for some classes and a hidden bug for others.

Seeing the defaults

class Account {
    private final String owner;
    private final String number;
    Account(String owner, String number) { this.owner = owner; this.number = number; }
}

Account a = new Account("Ana", "A-1");
System.out.println(a);                  // Account@4517d9a3
System.out.println(a.getClass().getName());  // Account

println(a) calls toString() for you. The class has no toString of its own, so the one from Object runs. The number after @ will be different on your machine and may change between runs.