06 Methods and Modular Programming

What Methods Do

A Method is a named, reusable block of code designed to perform one specific task. A method definition normally identifies a name, its inputs, the instructions it executes, and optionally the result it returns.

A method does not run merely because it has been defined. It runs when another part of the program invokes it. This separation lets programmers define behavior once and use it in multiple places.

A well-designed method usually has one clear responsibility. A method that calculates a total is easier to understand and maintain than one that calculates a total, validates input, prints a report, and saves a file all at once.

Takeaway: Define methods around meaningful tasks, and keep each method focused enough that its purpose is easy to explain.

Inputs: Parameters and Arguments

A parameter is a named input in a method definition. An argument is the actual value supplied when the method is called. For example, a greeting method might define a parameter named name; calling it with Maya supplies Maya as the argument.

A method can accept no inputs, one input, or several inputs. The order of supplied arguments normally corresponds to the order of the parameters. Some languages also support named arguments or default parameter values.

Parameters make a method reusable because its instructions can work with different data instead of depending on one fixed value. They also make a method's important inputs visible to anyone reading or testing it.

Takeaway: Parameters belong to the definition; arguments belong to a particular call.

Producing Results

A return value communicates a result from a method back to its caller. The caller can store the result, display it, compare it, or use it in another calculation. A method can return a calculated value, a Boolean decision, or another kind of result.

Returning a result is different from printing one. Printing displays information immediately, whereas returning makes the result available to the calling code. A method whose purpose is only an action may return no useful value. A return statement also ends the current method, so instructions after it do not execute.

For example, a temperature-conversion method can return the converted temperature, allowing one caller to display it and another caller to use it in a later calculation. A decision method can return whether a number is even, allowing the caller to choose what to do next.

Takeaway: Return values communicate results; printing is an immediate side effect and is not a substitute for returning data.

Scope and Local Data

Scope describes where a name can be accessed. A local variable created inside a method normally belongs only to that method. Parameters are also local to a particular method call. When the method finishes, its local names normally go out of scope.

This separation protects internal data. For example, a method can calculate an intermediate tax amount and a total without allowing unrelated code to refer to those names directly. Each call receives its own parameter values and local variables.

Prefer local variables when possible. Excessive dependence on global variables can make methods harder to understand and test because their results may depend on hidden data. A method is more predictable when important inputs arrive through parameters and its result leaves through a return value.

Takeaway: Keep temporary data local and make a method's important dependencies explicit.

Calling and Combining Methods

A method call asks the program to execute a method with particular arguments. The general sequence is:

1. The program reaches the call.

2. It associates each argument with the corresponding parameter.

3. It executes the method body.

4. It produces a result, if the method returns one.

5. It gives that result back to the calling code.

Methods can call other methods. A larger operation can therefore be assembled from smaller operations, such as obtaining a subtotal, applying tax, and creating a final receipt. A method can also call itself; this is recursion. Recursive methods require a base case that stops further calls.

Takeaway: Calls connect focused methods into a larger execution sequence.

Decomposing Complex Problems

Decomposition divides a complex problem into smaller subproblems. For a grade-processing program, separate methods might validate grades, calculate an average, assign a letter grade, and create a report. Each method can then be understood and tested independently.

A practical decomposition process is:

1. State the overall problem in one sentence.

2. List the major actions needed to solve it.

3. Turn each action into a possible method.

4. Identify the input and result for each method.

5. Implement and test the methods separately.

6. Combine them with a coordinating method.

Decomposition improves clarity, reuse, maintenance, and debugging. If grading boundaries change, the relevant method can be updated without rewriting the entire report process.

Takeaway: Divide a problem according to meaningful responsibilities, not merely according to individual lines of code.

Interfaces, Reuse, and Abstraction

Reusable methods need a clear interface: the information a caller needs in order to use the method. This includes the method's name, parameters, expected values or types, and return result.

A reusable method should have a descriptive name, accept necessary data through parameters, return a useful result when appropriate, avoid unexpected changes to unrelated data, and handle invalid input consistently. A short comment or documentation is helpful when the behavior is not obvious.

A method should not be made artificially small. The goal is to create meaningful units that make a program easier to understand and change.

Abstraction allows a coordinating method to express a solution in broad steps while lower-level methods handle details. For example, a high-level order-processing method can validate items, calculate a total, and create a receipt without exposing every implementation detail at the point where the overall process is described.

Takeaway: A clear interface and useful abstraction allow code to be reused without requiring callers to understand its internal implementation.

Side Effects and Predictability

A side effect is a change a method makes outside its local calculation. Printing, writing to a file, modifying an object, and changing a global variable are examples.

A method that only calculates and returns a result is often easier to test and reuse. Displaying that result can be handled by a separate method when needed. This separation allows the calculation to work in programs that use a graphical interface, a file, or no user interface at all.

Side effects are not always wrong. They are useful when a method's purpose is to display information, update an object, or save data. They should be intentional and documented so that callers can predict what the method will change.

Takeaway: Separate calculations from side effects when practical, and make necessary external changes explicit.