Parameters in Programming

Understanding parameters and how they are used can be frustrating. It’s an essential part of programming, and if you don’t take the time to master it, your code will be forever hindered, and you will be banging your head against your keyboard indefinitely until you rage quit technology. In this post I will discuss what parameters are, how they are used, and the difference between formal, and actual parameters.

This was originally a school assignment. The text book that’s referred to is called Introduction to Programming Using Java Seventh Edition by David J. Eck. A downloadable free PDF is available from here. The references to TextIO is a Java file that makes it easier for beginners to use I/O in Java. The file can be added to your Java project by copying it from this link. 


One of the concepts of parameters in programming has to do with information hiding. In the textbook, Introduction to Programming Using Java, the concept is repeatedly referred to as “black box”. The idea is that when we write reusable blocks of code, called subroutines, they shouldn’t have to be analysed in order for a programmer to use those subroutines. Think about how we use TextIO or any other Java class, and all of its methods (subroutines belonging to an object).

How information hiding works.

When you use TextIO.getlnInt() for example, you don’t have to read the code inside of TextIO or inside of the function, getlnInt(). You, as a programmer are able to take advantage of the function without knowing exactly how it works. All you know is what it returns and how to use it. Why it works isn’t important.

Now, getlnInt() doesn’t have any parameters, but the idea remains the same when we use other subroutines that do take in parameters. Such as TextIO.putln(). This method takes a parameter as a string, and then outputs that value to standard output (in most cases that’s the console inside your IDE). You don’t need to know how the method works under the hood, only how to use it and where it can be applied.

A fun analogy for this, is how a video game console might work. I love retro gaming so let’s use the classic Nintendo Entertainment System (NES) as our example. The NES uses game cartridges as it’s input, and the images you see on your TV screen are the output. The NES can be thought of as a black box like a subroutine in Java.

It takes in a video game cartridge as a parameter, and it returns interactive images to a display such as your TV. You do not need to know how a NES works in order to use one. There is no need to open it up and look at the components inside. You simply need to know what kind of information can be passed as a parameter or an argument, and know what results you can expect.

Formal Parameter VS Actual Parameter

Now, the reason I use the word argument, is because this is the word we use to describe a parameter that is being passed to a subroutine from a subroutine call statement.

Example:

TextIO.putln("Hello, World!");

In the above, the string between parenthesis is known as an argument. In our book, this is also referred to as an actual parameter.

When we define a subroutine, we define the arguments that the subroutine will require when it is called. These values are what we call parameters, or formal parameters.

Example:

private int addTwoNumbers (int a, int b) {
    return a + b;
}

In this example I made a function that returns an int. But it also takes in two parameters as ints to create the return value. The variables inside parenthesis are whats called parameters.

Here’s how we would call this function.

int sum;
sum = addTwoNumbers(5,5); // adds 5 + 5 
System.out.println(sum);  // output will be 10

In this example, the integers 5, and 5 are the arguments.

To reiterate, the values that we pass to these parameters from the subroutine call, are the arguments, or formal parameters. And the place where we define those arguments are called parameters, or actual parameters.

Interface

The whole point of having parameters isn’t just to do with information hiding. You should notice that TextIO.getlnInt() has no parameters and still achieves the concept of a “black box”. Parameters simply extend from the concept of information hiding. What parameters really achieve is what’s called an interface.

By using parameters in our subroutines, we can make the subroutine more generalized and flexible. Its use can be applied to many situations. The programmer using the subroutine is able to get many different results by passing different arguments. The arguments that can be used and how they are used is what’s called the interface.

Bringing it back to the NES analogy we can look at the insertion of a game cartridge as an interface. The output of a NES varies depending on what kind of video game or argument is passed to the console (subroutine). Having an interface allows the NES to be reusable in many, many different ways. Instead of buying one NES that can only play one game, and then buying another NES to play a different game, we can play hundreds of games on just one NES.

Conclusion

As we learn more about building subroutines, classes, and object-oriented design. We will continue to see how important parameters are in designing our applications. The way you, and other programmers interface with the subroutines you write is the foundation of good software engineering. Understanding how parameters are used, and how to use them effectively is crucial in becoming a good programmer.

Understanding the concepts covered in this post are what’s going to help you use classes like TextIO more effectively, and be comfortable using API’s (Application Programming Interface’s), libraries, and frameworks – all of which have interfaces built using parameters. Soon we will all be building out our own API’s and libraries, and parameters are going to be a major component in the design.

I hope this post has helped you make sense of parameters. Let me know any questions you may have in the comments below!

Happy coding,

Dan

Leave a Reply