PDA

View Full Version : help with worker project and polymorphism....


mia_tech
02-21-2009, 06:53 AM
guys I'm working on a project for homework, and I've been asked to use polymorphism, now I've implemented what the workerTester class wants in other words, I'm getting the right ouput printed to screen, but I'm not sure I'm implementing polymorphism.... could someone tell me if I'm doing any polymorphism and if not how could I implemented....
Worker Class
public class Worker {
//variables
double rate;
String name;
double weekSalary;
//construct worker that takes in name and salary
public Worker(String name, double rate)
{
this.name = name;
this.rate = rate;
}
//method to compute week pay
public double computePay(int hours)
{
this.weekSalary = this.rate * 40;
return this.weekSalary;
}
//getters
public String getName()
{
return name;
}
}

HourlyWorker Class
public class HourlyWorker extends Worker{
//construct HourlyWorker that takes name and rate
public HourlyWorker(String name, double rate)
{
super(name, rate);
}
//method for calculating weekly pay
@Override
public double computePay(int hours)
{
if(hours <= 40)
{
this.weekSalary = this.rate * hours;
}
else
{
this.weekSalary = this.rate * 40;
int excess = hours - 40;
double overTime = (excess * 40) * 1.5;
this.weekSalary += overTime;
}
return this.weekSalary;
}
}

SalariedWorker Class
public class SalariedWorker extends Worker{
//construc SalariedWorker that takes in name and rate
public SalariedWorker(String name, double rate)
{
super(name, rate);
}
//method to compute week pay
@Override
public double computePay(int hour)
{
return super.computePay(hour);
}
}

Fou-Lu
02-21-2009, 07:09 AM
That correct.
Polymorphism is simply the act of dynamic binding. So, when you're main constructs an HourlyWorker, the method to calculate the pay used is from the HourlyWorker class instead of the parent Worker class. Its the usage of overriding that's performing the dynamic binding.
I would probably make the Worker into an abstract class. Since the hourly and salaried workers work in this example, it would be more complicated to handle a commission worker, since they don't really have a rate. I'd suggest you're hours to be as a double instead of an integer as well, hourly employees can work partial hours and that would make for easy calculations for the commission employee (where the 'rate' would be the percentage earned, and the hours would be the amount sold).

mia_tech
02-21-2009, 07:12 AM
ohh, I was missing the main application ....
WorkerTester Class
public class WorkerTester {

public static void main(String[] args)
{
Worker s = new SalariedWorker("Sally", 40);
Worker h = new HourlyWorker("Harry", 40);
System.out.println(s.computePay(30));
System.out.println("Expected: 1600");
System.out.println(h.computePay(30));
System.out.println("Expected: 1200");
System.out.println(s.computePay(50));
System.out.println("Expected: 1600");
System.out.println(h.computePay(50));
System.out.println("Expected: 2200");

}
}

mia_tech
02-21-2009, 07:18 AM
That correct.
Polymorphism is simply the act of dynamic binding. So, when you're main constructs an HourlyWorker, the method to calculate the pay used is from the HourlyWorker class instead of the parent Worker class. Its the usage of overriding that's performing the dynamic binding.
I would probably make the Worker into an abstract class. Since the hourly and salaried workers work in this example, it would be more complicated to handle a commission worker, since they don't really have a rate. I'd suggest you're hours to be as a double instead of an integer as well, hourly employees can work partial hours and that would make for easy calculations for the commission employee (where the 'rate' would be the percentage earned, and the hours would be the amount sold).

Thanks for the explanation... yes, I realized that polymorphism says that: methods vary depending on the actual type of the object. About the abstract class, I'm going to google it, so I haven't got there yet on classes, but if you don't mind, please argument about it.

Fou-Lu
02-21-2009, 07:31 AM
Worker is a non-existant type. In that, there is no such thing as a worker, but there is an HourlyWorker or a SalariedWorker which are typeof Worker. With this approach, you would convert the Worker class into an abstract class. Abstract classes cannot be instantiated, so you know that the provided worker is a Worker, but you needn't have the Worker provide the details of the implementation.
Abstracts are used when you know that extensions will be made, and you want to force each extension to handle the details of a method implementation. With the Hourly and Salaried worker examples, I'd create an Abstract worker that forces the implementation of the calculatePay:

abstract class Worker
{
public abstract double calculatePay(double hours);
}

class HourlyWorker extends Worker
{
public double calculatePay(double hours)
{
return this.rate * hours;
}
}

class SalariedWorker extends Worker
{
public double calculatePay(double hours)
{
return this.salary;
}
}

class CommissionWorker extends Worker
{
public double calculatePay(double hours)
{
return this.commission * hours;
}
}

I'm about 95% certain that in java you can rename you're input variables as well, so long as they match the signature (in this case: return double, parameter double).

That help?


I should mention as well, that the usage of Patterns are becoming more widely accepted. The pattern for this would be a design pattern which converts the subclasses from 'is a' usage so that the Worker class instead 'has a' worker. These no longer apply dynamic binding on them, but remove the necessity for handling child extensions and redefining currently existing code. They are also more advanced in nature.