Inheritence issue?

[|2eM!x]

Okay so I will just write some psuedo code here to explain my problem

I have a class named Employee, in which other classes inherit from. It has the following methods which the other classes do not overwrite:

Pay()
getName()

Now, one of the classes that inherit it (FactoryWorker) creates its own method:

workOnPart(String PartName)

So in my program, I thought doing this was legal using inheritence:

Employee myEmployee;

and later on I wanted to dynamically set it to FactoryWorker like so

myEmployee = new FactoryWorker();

This works, however if I try to access workOnPart() it tells me if could not find the symbol. Is there a way to do it in the same fashion? Obviously my wayy doesnt work. Hopefully it was all legible and makes sense.

[penagate]

It can't find workOnPart because you've declared the variable as an Employee, which doesn't contain that method. You need to cast it to a FactoryWorker.

((FactoryWorker)myEmployee).workOnPart(...);

But that's not good; a sign of bad design. The usual way is to make methods for dealing with specific employee types and type their arguments using the specific type.

void tellThatGuyToGetOffHisButtAndDoSomeWork(FactoryWorker guy, String whatToDo)
{
  guy.workOnPart(whatToDo);
}

That way, there's no explicit casting involved; you can code the method without worrying about types; and any type checking errors will be reported in a more logical place in your code.

Obviously, that's a contrived example: you hopefully wouldn't need to make a method that only did that.


As a side note, declaring variables without initialising them is generally a bad practice. You should only declare a variable when you can give it a meaningful value. Otherwise, unless you're the most meticulous (and unproductive) coder in the world, you'll run into some sort of error related to an uninitialised variable.

[|2eM!x]

Interesting!

The reason behind this is, I have 3 classes that inherit Employee. I want the user to input which class theyd like, and then I cast the variable to be the type they asked for -- ex:

switch(in.nextInt()){
     case 1://FactoryWorker
     worker = new FactoryWorker();
     worker.workOnPart()
     break;
     case 2://OfficeWorker
     worker = new OfficeWorker();
     worker.doPaperWorkorSomethingElseInteresting();
     break;
}
worker.getPayment();

I liked it this way because they both would have getPayment, and I could use a couple less lines of code each switch case.

I think you get the point. I thought late binding let me do the above. I will look into your code a bit, thanks

[DeadEyes]

Would this be a case for interfaces?

public interface IWorker{
  public void doWork();
}

public class FactoryWorker() implements IWorker{
 public void doWork(){ System.out.println("sweat");}
}

public class OfficeWorker() implements IWorker{
 public void doWork(){ System.out.println("type");}
}

:
IWorker worker = null;
switch(type){
  case 1
    worker = new FactoryWorker();
  case 2
    worker = new OfficeWorker();
}
worker.doWork();

[CornedBee]

Nope, interface changes nothing. It's a simple issue of design. The places that deal with employees in general need only know that they're dealing with employees. The places that deal with factory workers, e.g. those telling them what to do, need to know that they're dealing with factory workers, and factory workers only. The design of the company could look something like this:

class Company {
  private Accounting accounting;
  private Production production;
}

class Accounting {
  private List<Employee> allEmployees;
  public void distributePayChecks() {
    for(Employee e : allEmployees) { e.Pay(); }
  }
}

class Production {
  private List<FactoryWorker> workers;
  public void dailyWork() {
    for(Item i : workLoad) {
      getFreeWorker().makeItem(i);
    }
  }
  private FactoryWorker getFreeWorker()
  {
    for(FactoryWorker w : workers) {
      if(w.isFree()) { return w; }
    }
  }
}

Obviously, every employee would be registered several times, once in accounting and once more in the place he actually works.