Olá rmalati, apenas complementando o que nosso amigo asaudate lhe disse, faz sentido a classe Funcionário ser abstrata, afinal em uma empresa todos são Funcionários, porém um funcionário pode ser: gerente, supervisor, faxineiro, etc…
Faz sentido criarmos um objeto do tipo gerente, supervisor, faxineiro,etc… Mas não faz sentido nesse caso instanciarmos uma classe Funcionário, por isso concordo com você quando disse q sua classe Funcionário seria abstract. Vale lembrar que uma classe abstract pode conter métodos abstracts ou não.
seu método setIdadeFuncionário() será igual para todos os funcionários, afinal independente da posição hierárquica dos funcionários em uma empresa um método que “seta” a idade pra eles funcionaria da mesma maneira, tanto pro Dono da empresa quanto pra um faxineiro. Nosso colega asaudate explicou bem isso.
Usando um exemplo da apostila da Caelum ( vi que você está estudando por ela ) eles usam o método getBonificacao, para um funcionário. Nesse caso é interessante deixar esse método abstract porque nem todos os funcionários são bonificados da mesma maneira, mas eles são bonificados, ai você diz pra sua classe Funcionário : Quando houver alguma classe concreta que herde de mim, ( por ex: Gerente) ela será obrigada a reescrever o método getBonificacao.
Ficaria + ou - assim:
public abstract class Funcionario {
private double salario;
abstract double getBonificacao();
public double getSalario(){
return salario;
}
}
Herdando a classe Funcionário e reescrevendo o método getBonificação
class Gerente extends Funcionario {
public double getBonificacao() { //método reescrito para o funcionário Gerente
return this.getSalario() * 1.4 + 1000;
}
}
Você terá atributos private em sua classe Funcionario, por ex:
private double salario;
E quando precisar manipulá-lo ou acessá-lo, pode fazer isso com métodos gets e sets e não quebrará o enclapsulamento, que era sua preocupação inicial.
Espero ter ajudado.
Até.
