Methods and Modularity

A method is a named, reusable block of code that takes some inputs (called parameters) and (optionally) produces an output (its return value). In other languages a similar idea is called a function or procedure. In Java, all methods belong to a class, which is why we always call them methods.

If variables are nouns, methods are verbs.

Why methods exist

Imagine writing a 500-line main method that does everything. By the time you reach line 400, even you have forgotten what lines 100-200 do. The fix is to give each chunk a name — a method — and call the method from main.

A well-designed Java program reads, at the top level, like a story: short sentences, each delegating to a method whose name makes its intent obvious.

This is modularity: each method is a small module that does one thing.

Anatomy of a method

returnType methodName(paramType paramName, ...) {
    // body
    return someValue;     // unless returnType is void
}

A few rules:

• The return type says what kind of value the method gives back. Use void if it returns nothing.
• The name should be a verb or short verb phrase: add, printReport, findLargest. Lower-case first letter, camelCase for multi-word names.
• The parameters are local variables that are initialized from the caller's arguments.
• return immediately ends the method and gives its argument back to the caller.

A first example

Notice:

• square is declared static because we are calling it from another static method (main) without first creating an object. We'll drop static in the next chapter when methods belong to instances.
• The caller passes a value; the method receives it as a new local variable x. Changing x inside square would not affect the caller.

A call diagram

Each call is a tiny, self-contained conversation. main doesn't care how square does its job; it only trusts that the return value is the square of the argument.

Why short methods are better than long ones

A few rules of thumb that have served programmers well for decades:

• A method should do one thing. If you find yourself writing the word "and" in its description, split it.
• A method should fit on a screen. Roughly: 5-20 lines. Occasionally longer for genuinely linear sequences, but rarely.
• A method's name should be honest. If compute() also prints to the screen, rename it to computeAndPrint, or split it.

These rules are not bureaucracy. They are how you keep your codebase from collapsing under its own weight (recall the software crisis from chapter one).

A multi-method example

Let's compute the average and the maximum of a list of integers, each in its own method.

Read main. You can understand the story — load scores, take the average, take the maximum, print both — without reading the bodies of sum, average, or maximum. The methods provide abstraction: callers see the what, not the how.

If tomorrow someone discovers a faster way to compute the maximum, they can replace maximum's body without touching main.

Parameters: by value, by reference (almost)

This is a subtle point and worth stating once carefully.

When you call a method, the arguments are copied into the parameters. For primitives, that means the value itself is copied (so changes inside the method don't affect the caller). For reference types, the reference (the address) is copied — but it still points at the same object on the heap, so the method can mutate the object's contents.

This trips up nearly every Java beginner once. Take it slowly.

Method overloading

Java lets you have multiple methods with the same name, as long as their parameter lists differ. The compiler picks the right one based on the argument types.

This is purely a convenience for readers — the same name across methods that conceptually do the same thing for different inputs.

A small multi-file challenge

Write a MathTools class with two methods, and a Main that uses them. Use small, single-purpose methods.

min = 2
max = 91

You can now build small, well-organized procedural programs. Next we take the much bigger step that the whole story of this course has been pointing toward: objects and classes.