Question

So I’m new to java and I’m trying to wrap my head around this. So far I’m writing a public method that calls a private method, both of which are written in the same class. When testing the public method, I am able to call the public method against an object, employeeOne, whose parameters are supplied by the user. I’m not exactly sure whats going on with the private method call here though since it appears that I’m calling it on the class (i think) and not the objects with defined attributes.

So here is a private method that I have written inside a class called Employee:

private static double computeGrossPay()
{
    if (hoursWorked <= 40)
    {
        grossPay = (hoursWorked * payRate);
    }
    else if (hoursWorked >= 40)
    {
        grossPay = ((40 * payRate) + ((1.5 * payRate) * (hoursWorked - 40)));
    }
    return grossPay;
}

I was trying to figure out a way to call this method in another class and obviously since it is a private method I can’t call it anywhere outside of the class it is written in. So I wrote a public method that makes a call to the private method

public double grossPayDisplay()
{
    return Employee.computeGrossPay();
}

This is where my question comes into play: So far this code works but I’m not entirely clear on why it works.

Here is how I tested it:

System.out.println(employeeOne.grossPayDisplay());

employeeOne is an object created from the class Employee whose parameters are supplied by the user, my question is:

How does the compiler go from Employee in Employee.computeGrossPay() to employeeOne?

Or to reiterate how does

return Employee.computeGrossPay() 

actually pass attributes to computeGrossPay()?

Answer 1

computeGrossPay is a static method, which means it belongs to the class itself, rather an any particular Employee object. Static methods can only access other static members, so it looks like your fields like hoursWorked must be static too.

This “works” but it doesn’t seem correct to me. A field like hoursWorked is an attribute that should belong to each individual Employee – try removing static from that field’s declaration.

Now, you’ll probably get a compile error, since computeGrossPay is trying to access an instance (non-static) field when that method isn’t being called on an instance of Employee. For this reason computeGrossPay should probably be an instance method:

private double computeGrossPay() { ... }

And then it would be called like this:

public double grossPayDisplay()
{
    return this.computeGrossPay();
}

(which makes grossPayDisplay look a little pointless – you could just make computeGrossPay public)

Alternatively, computeGrossPay could stay static and take an Employee as an argument:

private static double computeGrossPay(Employee employee)
{
    if (employee.hoursWorked <= 40)
    {
        employee.grossPay = (employee.hoursWorked * payRate);
    } else if (hoursWorked >= 40)
    {
        employee.grossPay = ((40 * payRate) + ((1.5 * payRate) * (employee.hoursWorked - 40)));
    }
    return employee.grossPay;
}

But that’s pretty ugly and doesn’t make as much sense.

Above, I just assumed grossPay was also made an instance field too – but it feels a little strange how it’s being used. Since gross pay is something being calculated on the fly, it doesn’t seem like that should be saved in a field. Consider making it a local variable within the method:

private double computeGrossPay()
{
    double grossPay; //declare the local variable

    //assign it depending on hoursWorked
    if (hoursWorked <= 40)
    {
        grossPay = (hoursWorked * payRate);
    }
    else
    {
        grossPay = ((40 * payRate) + ((1.5 * payRate) * (hoursWorked - 40)));
    }

    //return its value
    return grossPay;
}

(doesn’t matter whether the method is static or not for that last point)

One last note: you’ll notice I kept treating payRate like a static field. I just did that as an example, but it seems like it could go either way: there could be a single pay rate for all employees, or each employee could have their own pay rate. That just depends on the context of your program and it’s up to you.