Introduction: More Methods
You have been working with methods since early in the semester, and today we will delve into more details about writing methods in Java.
You will also be working with loops and arrays again, so refer to Zybooks and previous labs/assignments for help.
Method Overloading
Method overloading allows multiple methods to be written with the same name, as long as the parameters of the two methods differ. If both the parameter types and the method names of two methods do not differ but the return types do, the program will not compile.
Let’s look at an example to illustrate why we may want to use method overloading:
The methods both return the sum of multiple numbers, but they take a different amount of integers as parameters:
public static int sum(int a, int b, int c){
return a + b + c;
}
public static int sum(int a, int b){
return a + b;
}
It may not make sense to define methods for as simple of an operation as summing numbers, but if a method is performing a similar function but varies in terms of parameters, it may be wise to use method overloading to simplify a program.
It is also possible to overload a constructor in the same you would a method. The syntax will be the same, parameters will just be included in one of the constructors.
Unit Testing
Unit testing simplifies the process of checking a program for correct behavior and output. Zybooks discusses this subject in more detail, but for today, we will run through a basic overview. It means that testing for the program is structured into individual parts or units of a program, often a method.
You have been doing this or been provided this throughout the semester to test your labs, but today, you will be writing your own small testbench, using assert statements and creating your own test cases. This will be more formal than the testing you have done previously.
What makes a good test case?
Since it is not possible to test all potential input values for a method, a programmer should choose a variety of input values they would expect for their program. Tests should also include border cases that may not be common but are potential extremes a method may encounter.
About the Lab
Today you will be working within a class called Wallet, that will contain variables to keep track of dollars and cents in the hypothetical wallet.
You have been given some starter code to assist with this lab. This includes:
- a default no-arg constructor to initialize the Wallet class
- a constant int array called COIN_AMOUNT to keep track of the cent amount of each coin, it contains the values {25, 10, 5, 1}
- a constant string array called COIN_NAME to keep track of the coin names with the values {“quarters”, “dimes”, “nickels”, “pennies”}
- Three class variables
- an int array called change to keep track of the number of each coin the Wallet has
- an int called dollars to keep track of the number of dollars the Wallet has
- a double called balance to keep track of the overall balance the Wallet has
- a method called printWallet() that prints out the information including the balance, dollars, and change of the Wallet.
You will be responsible for writing another constructor for this class, as well as two methods that represent paying for an item. You will also use unit testing to verify your code, and have been given some test code to start with.
Step 1 : Wallet(int quarters, int dimes, int nickels, int pennies, int dollars)
Create a constructor for the Wallet class that does not take any arguments.
This constructor should initialize all three class variables. The array change should be initialized to a new four element array, and dollars and balance should be initialized to 0. Initialize all elements in the array to 0.
Now, create a constructor that takes five arguments that are ints - quarters, dimes, nickels, pennies, and dollars.
The constructor should initialize the change array to a new int array, then initialize the appropriate elements in the array to the arguments.
Then, initialize the dollars class variable with the appropriate argument.
Finally, the method should call the updateBalance() method so the class variable balance is initialized to the correct value.
Step 2 : updateBalance()
Write a method called updateBalance() that depends on an instance of the class, and takes no parameters.
It should update the balance class variable based on the values in the dollars and change class variables.
The constant array COIN_AMOUNT may be helpful in calculating the cent amount based on the number of coins in change.
We have included a method called testConstructors() that will ensure the constructors are working as expected. Call it from main now.
Step 3 : payForItem(int costDollars, int costCents)
Write a method called payForItem() that takes two parameters, an int representing the dollar cost of an item and an int representing the cent cost. For example, if an item were to cost $3.24, calling the method with that cost on an object called w would look like this:
w.payForItem(3, 24);
This method should return a string with the following format:
You paid $3.24 and your balance is $2.01.
The above string should be returned UNLESS the cost of the item is greater than the balance, in which case, return “Inadequate balance” and do not subtract any amount from the balance or pay for a portion of the item.
Each dollar amount should only have two decimal places after the decimal (Hint: use string format!).
Remember to update the balance class variable after you have altered the amounts of dollars or cents by paying for the item.
Also, assume that this method will only be called on Wallet objects that can “pay for the item” with exact change, meaning that you do not need to worry about checking if change needs to be made. The template code provides comments within the method that should assist you how to approach this problem.
Step 4 : payForItem(double cost)
Write a method also called payForItem() to overload the method you just wrote. It should also return a string, but it will take a single parameter, a double, for the cost of the item.
Hint: Consider how you could utilize the work you already did in the previous method, instead of creating a whole new method from scratch.
Testing the payForItem() methods:
After writing the two payForItem() methods, use the static test method called testPayForItem() to check both methods.
Consider these questions when looking through the test methods to consider why we included the cases we did:
- What are some normal, expected input values for this method?
- What are the border cases for these methods?
- What should happen when the cost is more than the balance?
- What should happen if a negative cost is passed into the method?