لماذا نُخفي البيانات

Written Explanation

The problem: a field anyone can write

Here is an Account with plain, package-visible fields, the way a first class often looks:

class Account {
    String owner;
    double balance;
}

Any code that holds an Account can do this:

Account acc = new Account();
acc.owner = "Sara";
acc.balance = 100;
acc.balance = -500;

The last line compiles, runs, and leaves a bank account with a negative balance. Nothing in the language objects, because from Java's point of view -500 is a perfectly good double. The rule "an account never has a negative balance" exists only in your head.

Rules in every caller do not survive

You might answer: "I will check before I assign." So every piece of code that touches balance must remember to write the check. In a real program that is dozens of places: the deposit screen, the transfer code, the monthly interest job, the import tool a colleague writes next year. One forgotten check, in one place, and the rule is broken.

The problem is structural. The data lives in one class, but the rule is scattered over many. Whenever a rule and its data are far apart, the rule loses.

Encapsulation: data and its rules together

Encapsulation means two things that work together:

1. The data is hidden: fields are private, so only code inside the class can read or write them.
2. The only way in is through the class's methods, which apply the rules.

In bank terms, the balance is in the vault. The customer talks to the teller. The teller will happily process a deposit or a withdrawal, but will refuse to withdraw more than the account holds. The customer cannot bypass the teller, so the rule is enforced in exactly one place.

The Java keyword that builds the vault wall is private. The Java tutorial on controlling access says a private member can be used only inside the class that declares it, and recommends using the most restrictive level that makes sense, with public fields avoided except for constants.

What the compiler does for you

Make the fields private and the dangerous line stops compiling:

class Account {
    private String owner;
    private double balance;

    Account(String owner, double balance) {
        this.owner = owner;
        this.balance = balance;
    }
}

public class Main {
    public static void main(String[] args) {
        Account acc = new Account("Sara", 100);
        acc.balance = -500;
    }
}

Main.java:14: error: balance has private access in Account
        acc.balance = -500;
           ^
1 error

This is the best kind of error. It appears at compile time, before the program ever runs, and it appears for every caller, including the one written next year by somebody who never heard of your rule. The class has not yet enforced the rule (the constructor above still accepts -5; the next lessons fix that), but it has taken away the easy way around it.

The window: public methods

If everything is hidden, how does anyone use the object? Through methods you choose to make visible. The set of those methods is the class's public interface (not to be confused with the Java keyword interface, which you will meet in a later module). Think of it as the teller window: a small, deliberate opening in the wall.

A good public interface is small. Every method you expose is a promise you must keep. Every field you expose is a bigger promise: callers can read it, write it, and depend on its exact type.

Hiding lets you change your mind

There is a second benefit, easy to miss. When callers cannot see the fields, you can change how the data is stored, and the callers do not notice.

Suppose the account stores its balance as a double. Later you learn that decimals like 0.1 cannot be stored exactly in a double, and you decide to store whole cents in a long instead. If balance were public, every line of code anywhere that read acc.balance would break. With the field private, you change the class and nothing else:

class Account {
    private String owner;
    private long cents;   // the representation changed

    Account(String owner, double balance) {
        this.owner = owner;
        this.cents = Math.round(balance * 100);
    }

    void withdraw(double amount) {
        long c = Math.round(amount * 100);
        if (c <= 0 || c > cents) {
            System.out.println("Withdrawal refused");
            return;
        }
        cents -= c;
    }

    void show() {
        System.out.println(owner + " has " + cents / 100.0);
    }
}

The calling code, new Account("Sara", 100), withdraw(...), show(), is identical before and after. The window stayed the same; the vault was rebuilt behind it.

Hiding is not secrecy

private does not hide anything from people: anyone can read your source. It is a rule the compiler enforces about which code may touch which data. The goal is not secrecy but control: the class decides how its data may change.