Sample Question:

sdfsdfsf

JSR Notes:

Viewed initially, this assessment statement can stick out like a bit of a soar thumb, since it's here in the middle of some OOP material. Parameter passing will have been covered in the middle of Topic 4 - particularly as refered to in the Teaching Note above. But first of all being in the Option, we can go into a bit more depth. And secondly, the assessment statement itself is referring to "data items", and so we can take from that that this is mainly geared at objects being passed as paremeters, not necessarily primitives.

First, here's some "deja vu" notes for a kick start if you need one.

         Additional Coding Notes: Methods Notes - Part 2 - The Return Part
         Additional Coding Notes: Methods Notes - Part 3 - Parameter Passing

Parameter Basics

Paremeters are values sent to and "taken in" by a method, which the method requires to function as intended. In both the method definition, and the method call, the parameters list follows the method name, and is enclosed in a pair of parentheses. If there are not parameters required to be received (nor, therefore sent), the parentheses remain empty.

Example of a method which is supposed to recieve parameters:

public static void someMethod(int x, Car y)

And the call to it from another place:

someMethod(2, hondaAccord2018) //correct because int and String sent

Example of a method which requires no parameters:

public static void anotherMethod( )

And the call to it from another place:

anotherMethod( )

 

Matching the Number, Order, and Type

The parameters have to be of a particular number, and type and order when sent, to match, exactly the parameter list which is part of the specific method "signature".

Method Signatures

The signature of a method is it's specific:

• accessibility (public/private/protected)
• whether it is static or not,
• return type,
• name,
• and parameter list - ALL OF number, type, and order of the parameters

Here is a method signature of a public static method called method1, which takes in three parameters, an int, a boolean, and an array of Car objects, and which is void of a return value:

public static void method1(int x, boolean b, Car [ ] cArr)

And below is another different method. It is different because it has a different signature; namely the order of the parameters. Like the first example, this one is public and statc, it is also called method1, and it even takes in an int and a boolean and array of Car objects, just not in the same order as the method above:

public static void method1(boolean b, Car [ ] cArr, int x)
// Ok. This is a different signature than above.

With the different order of parameters we can say that the two signatures are different. And since they are different signatures, both of these methods could exist in the same class.

But the following method could not be in the same class as the first one above:

public static void method1(int num, boolean isRaining, Car [ ] carArray)
// Not Ok. Such a signature already exists.

This signature is already taken by the first method above. (Note that the identifier names of the parameters makes no difference, it's their number, type, and order that counts.)

Full Example

So, for example, a method might be:

public static void aMethod(boolean b, Car [] c){
    if(b){
    for(int i = 0; i < c.length; i++){
        sout(c[i].getCarMake());
    }
    else{
        sout("Sorry, you sent false as the boolean variable!");
    }
}

If using this method, we would have to send three, and exactly two, "arguments", to be received as "parameters", and send them in exactly the following order: boolean, Car [ ], such as:

aMethod(true, Car [] cars);

And the output of this might be:

Ford
Mercedes
Chevrolet

 

Arguments vs. Parameters

It's actually not a bad idea to get nitpicky with this and note that the data that is sent to the method call is best refered to as "arguments", and the copy of that data received by the method is what is best refered to as "parameters". The reason this is good to note is that in memory, they really are two differnent things. Copies, yes, but two different things in memory. This has two major implications, in two situations.

Primitives sent (copied) as Arguments

A primitive value "sent" to a method, where the copy of that method is altered, is not itself changed back where it was "sent".

public static void main(String [ ] args){
    int x = 3;
    System.out.printnln(x); // we see 3
    aMethod(x);
    System.out.printnln(x); // we still see 3. x was not changed, a copy of it was
}
public static void aMethod(int a){
    System.out.printnln(a); // we see 3
    a = a * 2;
    System.out.printnln(a); // we see 6
}

//Overall Output:
3
3
6
3

Objects' ADDRESS sent (copied) as Arguments       (This includes Arrays)

When an object (including an array) is "sent" as an argument, the same thing happens: a copy of it is made in the receiving method. But that copy is A COPY OF THE ADDRESS at which the original array resides. So any changes made via the copied address (the received parameter) will be reflected in what both are pointing to, the object or array itself. So changes to the array in the called method will be changes to the array in the calling method.

public static void main(String [] args){
    int [] arr = {101, 103, 106, 109};
    System.out.printnln(arr[2]); // we see 106
    aMethodTakingAnObject(x);
    System.out.printnln(arr[2]); // we don't see 106. We see 206, 
                                        reflecting the changes made to the array in aMethod().
}

public static void aMethodTakingAnObject(int [] a){
    System.out.println(arr[2]); // we see 106
    arr[2] = arr[2] + 100;
    System.out.printnln(arr[2]); // we see 206
}

//Overall output
106
106
206
206

Final Thoughts

And one final term point is that in some programming environments we talk of formal and actual parameters, but with Java and OOP, just calling the data sent and taken in "parameters" is fine.

Finally, do match all of this up with OOP constructors, set methods, and other methods which take in parameters. It would be good to look at a full OOP program with the above information on parameters in mind.