Reading a Method Signature

A method call is a promise, and the signature is where that promise is written down. The return type tells you what kind of value you get back when the call finishes: a double, a boolean, a String, or void if nothing comes back. The name tells you what to call it. The parameter list tells you exactly what you must hand over to use it, in order, by type. None of these three jobs overlaps, which is exactly why you need all three to know what a method does from the outside.

Take public double average(int[] data, int n). Before reading the body you already know: pass it an int array and an int, in that order, and it will hand back a double. Whether it sums the whole array or just the first n elements is hidden inside, but the shape of the deal is fixed. This is the whole point of a signature: it lets you use a method correctly as a black box, which is exactly what happens every time you call a library method you never wrote.

Signatures also control overloading. When two methods share a name, Java decides which one runs by matching the types and number of arguments at the call site against each method's parameter list. That matching only looks at types and order, never at the names you gave the parameters, which is why two methods can look different on the page but still collide at compile time. This sets up everything later in the unit about calling methods on objects: once you can read a signature, you can predict what any method needs and returns before you ever see how it works inside.