عندما يتوقف الكود الإجرائي عن التوسّع

Written Explanation

Procedural: data over here, logic over there

In procedural code the data and the code that works on it are separate things. The data lives in variables. The logic lives in methods. Each method receives the data it needs as parameters and sends a result back or changes what it was given.

For a single account this is perfectly good:

public class Single {
    static int deposit(int balance, int amount) {
        return balance + amount;
    }
    public static void main(String[] args) {
        int balance = 10000;          // 100.00 in cents
        balance = deposit(balance, 5000);
        System.out.println("Balance: " + balance);
    }
}

Output:

Balance: 15000

One variable, one method, nothing to confuse. Now the bank gets customers.

Growing to many accounts: parallel arrays

A bank with 1,000 accounts cannot have 1,000 separate variables. You already know the answer from BEG-015: use arrays. An account has an owner and a balance (and later a number, a currency, and more), so you need one array per property:

String[] owners   = {"Ana", "Omar"};
int[]    balances = {10000, 5000};

These are parallel arrays: index 0 in both arrays describes Ana's account, index 1 describes Omar's. The link between them exists only in your head and in your code's discipline. Java does not know that owners[1] and balances[1] belong together.

The methods now need the arrays and an index to say which account:

static void deposit(int[] balances, int i, int amount) {
    balances[i] += amount;
}

Problem 1: related data is split apart

Everything that describes one account is scattered over several arrays. To show one account you must pass several arrays and an index. To add an account you must add an element to every array, and keep the positions in step. Nothing in the program says "these values form one thing".

The danger is silent. Suppose you sort the owners alphabetically but forget to move the balances in the same way. Both arrays stay valid, the program compiles, and every balance now belongs to the wrong person (see Example 2).

Problem 2: nothing protects the data

balances is an ordinary array. Any method, and any line in main, can write any value anywhere:

balances[0] = -99900;   // legal; no rule is checked

The deposit method may be careful, but nothing forces other code to go through it. In a large program written by many people, "everyone will remember to call the right method" is not a strategy. A rule such as "a balance never becomes negative through a deposit" is only as strong as the weakest line that ignores it.

Problem 3: change spreads everywhere

Next month the bank adds a new property: a currency for each account. In the array design that means a new array currencies, plus a change to every method that must now carry the extra array and index, plus a change to every place that adds or removes an account. With ten methods, that is ten edits and ten chances to forget one. The compiler will not always tell you: a forgotten update in a sorting routine compiles fine.

The object-oriented answer

Object-oriented programming organizes a program around objects. An object bundles the data that describes one thing (its state) together with the methods that work on that data (its behavior). Instead of three arrays and a loose deposit method, the program has account objects, and each one knows its own owner and balance and can deposit into itself.

Compare how the same deposit reads:

In the procedural line the caller must know which array, which index, and that the arrays line up. In the object-oriented line the caller names the account and says what to do; the account takes care of its own balance. The Java tutorial describes this bundling as a main benefit of objects: the object's code can be written and maintained on its own, and details can be hidden from the outside. (Hiding details has its own module later.)

Here is the honest summary. OOP does not make a program faster, and it does not make a small program better. It makes a growing program easier to keep correct, because related data sits in one place, the rules sit next to the data they protect, and a new property is added in one place. You will write the Java syntax for it in the next module; for now, learn to see the problem it solves.