عرض عملي: بناء الآلة الحاسبة دالة بعد دالة

Written Explanation

The plan: three layers

We build in this order, running the program after each step:

1. Math layer: add, subtract, multiply, divide, power. Each takes numbers, returns a number, prints nothing.
2. Input/output layer: printMenu, readNumber, printResult. These talk to the user and do no maths.
3. Control layer: runBasic, runPower and main, which read the menu choice and connect the other layers.

The rule behind the layering is the one from Lesson 2: methods that compute return values; methods that show or read values do the printing and reading. Because of it, the maths layer works whether the result goes to the screen, a file, or (later) a web page, and each layer can be fixed without touching the others.

Step 1: the maths methods

static double add(double a, double b)      { return a + b; }
static double subtract(double a, double b) { return a - b; }
static double multiply(double a, double b) { return a * b; }

Test them from a temporary main (System.out.println(add(2, 3)); gives 5.0). We use double so the calculator accepts decimals.

Step 2: the planned mistake

Suppose that, in a hurry, you write add like this:

static double add(double a, double b) {
    System.out.println(a + b);   // prints instead of just returning
    return a + b;
}

It seems to work when you test it. The problem appears at the next feature. If you later want a "memory" that adds a result to a running total, printResult(add(a, b)) would show the number twice, once from inside add and once from printResult. A method that prints can never be reused quietly. The repair is to delete the println in add and let the caller decide how to show the value. Every maths method stays silent; only the printing layer prints.

Step 3: division and the zero problem

divide has one special case. For double values, Java does not throw an error on a zero divisor; it produces special values. A quick test on JDK 21 printed Infinity for 1.0 / 0 and NaN ("not a number") for 0.0 / 0. Integer division by zero, on the other hand, throws an ArithmeticException (1 / 0 crashed with / by zero in my run). Neither result is something a user wants to see as an answer.

So who should handle it? Two reasonable designs: the method signals the problem, or the caller checks first. Because divide has no good number to return for a zero divisor, we choose the second: the caller checks b == 0 and prints a friendly message, and divide stays a simple one-line method. Later modules introduce exceptions, which are the usual professional way for a method to report a problem; for now the check-first approach is clear and testable. The acceptance rule for the lab is the same: division by zero must be handled, not crash and not print Infinity.

Step 4: power with a loop

static double power(double base, int exponent) {
    double result = 1;
    for (int i = 0; i < exponent; i++) {
        result *= base;
    }
    return result;
}

The loop multiplies result by base, exponent times, starting from 1. That also handles exponent 0 correctly (the loop body never runs, so the answer is 1). The method assumes the exponent is zero or more; negative exponents are an extension you can add in the lab.

Step 5: the menu, input helpers, and the loop

printMenu prints the options. readNumber(Scanner in, String prompt) prints a prompt and reads a double. Notice that it receives the Scanner as a parameter. Creating a second Scanner on System.in in every helper is a source of bugs, so we create one in main and pass it down. Passing it copies the reference (Lesson 4), so every helper reads from the same input.

To keep main short we add two handler methods: runBasic for choices 1 to 4 and runPower for choice 5. Next, the whole program in its final form (factorial, the missing piece, is yours to add in the lab).