Java Methods and Program Design

Method structure and behavior

A Method is a named block of Java code that runs when called. Methods support procedural abstraction: a caller can use a method based on what it does without needing to know every implementation detail.

A declaration commonly contains these parts:

• An access modifier, such as public or private, controls where the method can be accessed.

• A return type states what kind of value the method produces, or void when it produces no value.

• A method name identifies the operation.

• A parameter list declares information that the caller can supply.

• A body contains the statements that execute during the call.

For example, a method with return type int can calculate and return a whole-number result. A void method can print a greeting or perform another action, but its call cannot be assigned to a variable or used as part of a larger expression.

A non-void method must return a compatible value on every possible execution path. A return statement immediately ends the current method and sends its result to the caller. A void method may use return without a value to exit early.

Takeaway

A method declaration describes how to call a task, what information it receives, and whether it produces a result.

Parameters, arguments, and return values

A Parameter is a variable declared in a method header, while an Argument is the value supplied in a method call. For example, in a method that computes an average from first and second, those names are parameters; values such as 4.0 and 10.0 are arguments.

The number, order, and types of arguments must match the selected method. If a method expects an integer followed by a string, supplying a string followed by an integer is not a valid call.

Java passes arguments by value. For a primitive value, the method receives a separate copy, so changing the parameter does not change the caller's variable. For a reference-type argument, Java passes a copy of the reference. The parameter and the caller's variable can therefore refer to the same object, allowing the method to change that object's contents. However, assigning a new object to the parameter changes only the local parameter; it does not redirect the caller's variable.

A Return value can be stored in a variable, printed, used in an expression, passed as an argument to another method, or returned by a larger method. For example, a Boolean result can be used directly as the condition of an if statement.

Takeaway

Match arguments carefully, distinguish changing an object from replacing a reference, and treat returned results as values that can flow into other expressions.

Method signatures and overloading

A Method signature consists of the method name and the ordered list of parameter types. The return type is not part of the signature.

Method overloading allows several methods in one class to share a name while accepting different parameter lists. A class might provide one method for two int arguments, another for two double arguments, and a third for three int arguments. The compiler chooses the version whose number and types of parameters best match the call.

Changing only the return type does not create a valid overload. Java also cannot distinguish two methods that have the same name and the same parameter types merely because their parameter variable names differ.

Do not confuse overloading with overriding. Overloading uses different parameter lists for methods with the same name. Overriding occurs when a subclass provides a new implementation of an inherited method.

A reliable call-analysis process

1. Identify the method name.

2. Count the arguments and identify their types.

3. Compare them with the available parameter lists.

4. Select the matching overloaded method without using the return type as a deciding factor.

5. Trace the selected method's statements and returned result.

Takeaway

When resolving a call, focus on the method name, argument count, argument order, and argument types.

Scope, local variables, and shadowing

Scope is the region in which a name can be used. A parameter's scope is the entire body of its method, and a parameter in one method is separate from a parameter with the same name in another method.

A local variable is accessible from its declaration to the end of its enclosing block. A variable declared inside an if block cannot be used after that block ends. Similarly, a variable declared in a for loop is generally limited to that loop. Local variables must be initialized before they are used.

A parameter or local variable can shadow a field with the same name. In a constructor such as Student(String name), the unqualified name name refers to the parameter, while this.name refers to the object's field. The keyword this makes the field reference explicit.

Each method call has its own parameter and local-variable values. When tracing nested or repeated calls, keep those values separate rather than treating identically named variables as one shared variable.

Takeaway

For every variable, ask where it was declared, which block contains it, and whether a closer declaration shadows another name.

Preconditions, postconditions, and contracts

A Precondition is an assumption that must be true immediately before a method runs. It can require valid parameter values, a non-null array, a nonempty array, a sorted list, a valid index, or an initialized object. The caller is responsible for satisfying the documented precondition unless the method explicitly promises to handle invalid input.

A Postcondition is a guarantee that must be true after the method finishes. It may describe a returned result or a side effect, such as leaving an array unchanged. A postcondition describes the method's observable guarantee, not necessarily the algorithm used to achieve it.

Together, these conditions form a contract:

1. The caller satisfies the precondition.

2. The method performs its task.

3. The method establishes the postcondition.

For example, a method that returns an array element might require that the array is not null and that the index is valid. Its postcondition might guarantee that the array is unchanged. If a method requires a nonempty array, calling it with an empty array violates the contract and may lead to incorrect behavior or an exception.

Takeaway

Check preconditions before trusting a call, then use postconditions to determine what can safely be assumed afterward.

Decomposition and helper methods

Decomposition means dividing a complex problem into smaller tasks. A Helper method supports another method by implementing one focused subproblem. The calling method can then express the overall algorithm at a higher level.

For a final-price calculation, one method can coordinate the process: first call a method that applies a discount, then call a method that adds tax. Each supporting method receives the information it needs and returns one intermediate result. The coordinating method remains readable because it describes the sequence of major steps instead of containing every calculation at once.

A well-designed helper method usually has one clear responsibility, a descriptive name, appropriate parameters, and a useful return value or action. Its contract should state important preconditions and postconditions. A counting method, for example, can receive an array, return the number of positive elements, and leave the array unchanged.

Decomposition provides several benefits:

• Readability improves because each method has a focused purpose.

• Testing becomes easier because smaller methods can be tested independently.

• Reuse increases when a helper can serve multiple callers.

• Debugging becomes more local because an error can be isolated to one task.

• Maintenance becomes simpler because one calculation can change without rewriting the whole algorithm.

Do not create a separate helper for every individual statement. A helper is most useful when it represents a meaningful subproblem and reduces the complexity of its caller.

Takeaway

Design methods around responsibilities: decide what each method should do, what it needs, what it guarantees, and whether it should return a value or perform an action.

A complete method-analysis workflow

When tracing or designing a Java method, combine the ideas in a consistent order:

1. Identify the method name and locate its declaration.

2. Match the argument count, order, and types with the parameter list.

3. Record the initial value received by each parameter.

4. Track local variables within their own scopes and keep separate calls separate.

5. Follow statements in execution order.

6. Distinguish changes to a shared object's contents from reassignment of a local reference.

7. Record the returned value, if any, and substitute it into the calling expression.

8. Check the precondition before relying on the method's behavior.

9. Apply the postcondition after the method completes.

10. If methods are overloaded, select by the parameter list rather than by return type.

This process supports both code reading and program design. When writing a method, choose a clear name, define the necessary parameters, select void or an appropriate return type, document the contract, and divide distinct subproblems into focused methods. When reading a method, focus on its inputs, local state, observable effects, and result rather than assuming that similarly named variables are shared.

Final checklist

• Does every non-void path return a compatible value?

• Are all arguments matched to the correct parameters?

• Is every variable used within its scope and initialized before use?

• Are preconditions satisfied?

• Does the method establish its promised postcondition?

• Is the method focused enough to be readable and testable?