When you finished the previous lesson your objects were boxes of data: Book holds a title and an ISBN, but it does not know how to do absolutely anything with them. All of BiblioTech's intelligence is still locked inside the two hundred lines of main, which calculates days late, applies the fine cap and classifies the severity as if the objects did not exist. This lesson supplies the missing half: behaviour. A method is a named operation that groups a set of instructions together, receives data, does a job and normally returns a result. It is the unit of code decomposition —what stops main from growing endlessly— and, in OOP, it is the way an object exposes what it knows how to do. By the end, calculateFine() will not be a loose block in the middle of a switch: it will be something a Loan knows how to do to itself.

1. Anatomy of a method
2. The return value and return
3. void methods
4. Parameter passing: Java always passes by value
5. What that means with primitives
6. What that means with references (and why it confuses everyone)
7. Method overloading
8. static methods versus instance methods
9. The this reference
10. Varargs: a variable number of arguments
11. Variable scope and shadowing
12. Good practice in method design
13. Recursion: a method that calls itself
14. Guided refactoring of BiblioTech
15. Common Mistakes and Tips
16. Exercises

This is the complete structure of a Java method:

The combination name + parameter types in order is called the method's signature. This one's signature is calculateFine(int). The return type is not part of the signature, and that will have consequences in section 7.

Vocabulary worth nailing down so you never confuse it again:

• Parameter: the variable declared in the method definition (int daysLate).
• Argument: the specific value passed when calling it (calculateFine(5) passes the argument 5).

Calling an instance method is always done through an object:

return does two things at once: it hands a value back to the caller and immediately ends the method's execution. You saw the second part in lesson 02-04, applied to flow control.

Compiler rules you must know:

• The returned value must be compatible with the declared type. A double method can return an int (automatic promotion), but an int method cannot return a double without an explicit cast.
• Every path must return a value. If the compiler finds a route without a return, it fails with "missing return statement".
• Code after a reachable return is always unreachable code and does not compile.

This method, for instance, does not compile:

Adding an else or a final return is enough to fix it. The second form —using guard clauses and leaving the general case at the end, without else— is the one you used in 02-01 and the one preferred in professional code.

When a method does something instead of calculating something, its return type is void:

In a void method you can use a bare return; to exit early, but you cannot return a value:

A useful design criterion, known as command-query separation: a method either changes the state (and returns void) or answers a question (and returns a value), but preferably not both. A method called getFine() that also marked the book as returned would surprise anyone reading it.

Here is one of the points where most people go wrong, even with years of experience. The rule is this, and it has no exceptions:

In Java, arguments are always passed by value. That is: when calling a method, the value of the argument is copied into the parameter.

What throws people off is what exactly is being copied in each case:

Hence the two consequences you have to memorise:

1. Reassigning the parameter never affects the caller (neither with primitives nor with objects).
2. Mutating the object the parameter points to does affect the caller (because it is the same object).

The next two sections demonstrate it with code.

Output:

The parameter days is a new variable on the method's stack, initialised with a copy of 20. Changing it does not touch the original variable. If a method must "modify" a primitive, the only way is to return the new value:

Now the interesting case. Two apparently similar methods, with opposite results:

Output:

The second call did nothing visible. Let us see why, in memory:

On entering reassignBook, the parameter book receives a copy of the address 0x1A: there are two arrows pointing at the same object. When the method does book = new Book(), it moves its own arrow to the new object 0x9F. main's arrow has not been touched. On leaving the method, the local stack disappears and the object 0x9F becomes unreachable.

In mutateBook, by contrast, no arrow is touched: the dot is used to modify the object both of them point to, and that is why the change is visible from main.

The sentence that sums it all up: you can change the contents of the object you are given, but you cannot change which object the caller's variable points to.

A practical corollary: String is immutable (module 1), so no method can alter the string you pass it. This never works:

To overload is to declare several methods with the same name and a different parameter list in the same class. Java picks which one to call based on the arguments.

What makes an overload valid:

Resolution rules, which Java applies in this order until it finds a match:

1. Exact match of types.
2. Primitive type promotion (int → long → float → double).
3. Autoboxing/unboxing (int ↔ Integer, module 1).
4. Varargs (section 10), which is always the last option considered.

Tip: overloading is useful when the variants do conceptually the same thing with different data. If two methods with the same name do different things, give them different names.

The difference is the same one you saw with fields in 03-02:

Real-world examples you already know: Math.max(a, b) and Integer.parseInt(text) are static because they need no state; scanner.nextLine() is an instance method because it depends on the state of that Scanner. And main is static because the JVM must be able to call it before any object exists.

Applied to BiblioTech:

The classic beginner's mistake, and probably the compiler message you will see most often:

The translation is literal: a static method is not associated with any object, so the question "whose elapsed days?" has no answer.

Inside an instance method, this is a reference to the object the method was called on. It has three uses:

a) Disambiguating when a parameter has the same name as a field (the most frequent use, and the one you will see constantly in constructors):

Without this, elapsedDays = elapsedDays; assigns the parameter to itself and the field does not change. The compiler does not complain; the error is silent.

b) Calling another method on the same object (optional, but sometimes more readable):

c) Passing the current object to another method:

Outside those cases, writing this. in front of everything is noise. In Java the dominant style is to omit it except when necessary. In 03-04 a fourth form will appear, this(...), for chaining constructors.

Varargs let you declare a parameter that accepts zero, one or many arguments of the same type. They are written with three dots:

Valid calls:

Inside the method, events is an array (String[]), with its length and its for-each loop. Arrays are studied in depth in lesson 05-01; here it is enough to know they are traversed like this.

Two mandatory rules:

• There can be only one varargs parameter per method.
• It must be the last in the list: register(String employee, String... events) is valid; the other way round does not compile.

You have already used varargs without knowing it: System.out.printf(String format, Object... args) is exactly this, and that is why it accepts any number of values after the format string.

A variable's scope is the region of code where it is visible. Summary:

Shadowing happens when a local variable or a parameter has the same name as a field: inside that scope, the name refers to the local variable, and the field is left "in the shadow".

Shadowing is not an error —in fact it is standard practice in constructors and setters, where the parameter is deliberately given the same name as the field—, but it demands that you remember this. when assigning.

These criteria separate a professional method from an improvised one:

• One method, one purpose. If describing what it does requires the word "and", it is probably two methods.
• Short. There is no magic number, but if a method does not fit on the screen, it is hard to reason about. The two hundred lines of main are the perfect counterexample.
• Verb-based, precise names. calculateFine, registerReturn, isAvailable. Avoid process, manage, handle or data.
• Boolean naming convention: isX, hasX, canX. if (book.isAvailable()) reads like a sentence.
• Few parameters. With more than three or four, consider grouping related data into an object. It is, once again, the problem of loose variables.
• Avoid boolean parameters. generateReport(true) says nothing when you read it. What is true?

• Do not mix abstraction levels. A method that calculates business rules should not also format with printf. It is the central topic of lesson 03-08.
• Document with Javadoc whatever is not obvious: what it returns, what it expects and what happens at the edge cases.

A method can call itself. That is called recursion, and every correct recursion has two parts: a base case that stops it and a recursive case that moves towards the base case.

Trace of sumUpTo(4):

Each pending call occupies a frame on the stack. If the base case is missing or never reached, the stack runs out and you get a StackOverflowError, which you will recognise because the trace repeats the same line hundreds of times.

Day to day, recursion shines with structures that nest by nature —trees, directories, expressions— and for everything else a loop is usually preferable, since it uses less memory. You will see it applied in lesson 05-09 (binary search) and in module 7 (walking directories).

The time has come to apply all this to the project. We will do it in two steps, because that is how it is done in real life: first extract, then move.

This is the code that lives today inside main's switch:

First improvement: pull it out into named methods.

And case "1" ends up like this:

Three readable lines instead of twenty. Notice the use of Math.max and Math.min, which replace the clamping ifs: Math.max(0, x) is "never below zero" and Math.min(x, cap) is "never above the cap". Less code and fewer places to get it wrong.

Step 1 improves readability, but leaves the business rules in the startup class. And those rules do not belong to the application: they belong to the loan. This is the genuinely object-oriented step.

And now, the before and after of the calculation in main:

Use from BiblioTechApp:

Output:

This is the moment BiblioTech becomes genuinely object-oriented: main no longer calculates anything, it just asks. And notice that calculateFine() internally calls calculateDaysLate(): a method can lean on another one of the same object, avoiding duplication of the clamping logic.

Let us also add behaviour to Book, which until now was pure data:

Look at lend() and returnItem(): they are the whole reason encapsulation exists. With a public field, anyone can write book.available = true; skipping the warning; with these methods, the operation goes through a single place that can validate. Lesson 03-07 will close that door for good.

• Forgetting this in a setter. elapsedDays = elapsedDays; compiles, does nothing and gives no warning. It is one of the most frustrating errors: the IDE flags it as "assignment to itself", listen to it.
• Believing that Java passes objects by reference. It does not: it passes the reference by value. The difference shows up exactly when you reassign the parameter, as in section 6.
• Trying to use instance fields from a static method. The compiler will say "non-static variable ... cannot be referenced from a static context". Ask yourself whether the method should be an instance method or whether it is missing the object as a parameter.
• Overloading by changing only the return type. It does not compile: the signature does not include the return.
• Methods that do two things. calculateAndSaveFine() is a warning sign in the name itself.
• Returning magic numeric codes. Returning -1 to mean "could not be calculated" forces every caller to know that convention. Until you have exceptions (module 6) or Optional (10-04), document the convention explicitly with Javadoc.
• Tip: use your IDE's "extract method". IntelliJ (Ctrl+Alt+M) and Eclipse (Alt+Shift+M) do step 1's refactoring automatically and without errors: you select the block, give it a name, and the IDE works out the parameters and the return.
• Tip: write the signature and the Javadoc first, the body afterwards. It forces you to decide what goes in and what comes out before getting lost in the implementation.

Extend the Employee class from the previous lesson with these methods:

• registerLoan(): increments totalLoans by one. If the employee is already at the MAX_CONCURRENT_LOANS limit, it does not increment and warns on the console.
• registerReturn(): decrements totalLoans, never below zero.
• canBorrow(): returns true if the maximum has not been reached yet.
• getInitials(): returns the employee's initials ("Marta Ruiz" → "M.R.").
• An overloaded version registerLoan(int amount) that registers several at once while respecting the limit.

Test them with Marta Ruiz until she reaches the limit.

Write a class PassByValueDemo with four static methods that receive, respectively: an int, a String, a Book that is mutated and a Book that is reassigned. Each one must print the value on entry and on exit. From main, call all four and print the state before and after each call. Then answer in writing: why does the String case behave like the int one and not like the mutated Book?

Write in Loan a static method simulateScale(int... elapsedDays) that receives any number of elapsed-day values and prints a table with: elapsed days, days late, uncapped fine, applied fine and severity. It must mark with <-- the first row where the fine reaches the cap. Reuse the existing methods and do not duplicate any business rule. Test it with simulateScale(5, 15, 20, 30, 60, 95, 100).

Solution 1

Test:

Output:

Keys: registerLoan(int) does not duplicate the limit check, it delegates to the no-parameter version; and Math.max(0, ...) in the return avoids a negative counter without needing an if.

Solution 2

Output:

Answer to the question. The String behaves like the int because it is immutable: toUpperCase() does not modify the original string, it creates a new one and returns it. Assigning it to the parameter only moves the local arrow, exactly as in case 4. It is not that Strings are passed differently —they are passed by value of the reference, like any object—, it is that there is no way to mutate them, so case 3 is impossible with String. That is one of the great advantages of immutability, and the reason why in 03-07 you will see that Book is a good candidate to become immutable too.

Solution 3

Call and output:

Three details deserve attention. First, the method is static because it simulates hypothetical situations: there is no real loan behind it, just numbers. Second, it reuses isMinorDelay(int), also static, without duplicating the threshold. And third, simulateScale() with no arguments is a perfectly valid call: it prints just the header, because varargs accepts zero elements.

One detail worth discussing: this method mixes calculation and presentation, exactly what section 12 advises against. It is acceptable in a diagnostic utility like this one, but remember it: in lesson 03-08 you will see why in business code that mixture is expensive.

Your objects now know how to do things. You master the complete anatomy of a method —modifiers, return type, signature, parameters, body— and the difference between parameter and argument; you know when a method returns a value and when it is void, and why it had better not do both. You have understood the rule that generates the most confusion in Java: everything is passed by value, including objects, whose reference is copied; hence mutating the received object affects the caller and reassigning the parameter does not. You know how to overload methods and you know the rules by which Java picks the right version, you tell static methods from instance methods and you understand why a static one cannot touch the state of an object it does not have. You handle this, varargs, variable scope and shadowing, and you have a catalogue of good practices for writing methods others can read. You have seen recursion with its base case and its risk of StackOverflowError.

And, above all, you have carried out BiblioTech's first big refactoring: the delay, fine and severity calculations have left main, become named methods and then moved to the Loan class, their rightful owner. main no longer calculates: it asks.

One loose end remains, an obvious one. Your objects are still born empty: new Loan() produces a loan with no book, no employee and zero days, and it has to be filled in field by field trusting that you forget none of them. In the next lesson, Constructors, you will close that door: you will learn to demand the essential data at the moment of creation, to overload and chain constructors, to control the order of initialisation and to validate the data so that no BiblioTech object can be born in an invalid state.