Herança

Boa Noite peresjuliao.

Cara qual a finalidade do seu Projeto??

Poderia criar uma classe Funcionario que contenha o objeto cargo

class Funcionario {


String cargo;
int salario;

etc...

}

Se for usar banco de dados tamben pode ser resolvido criando uma tabela funcionario relacionada com uma tabela cargo...

Não Cara,
basta fazer como o nosso amigo Diego C. Santos disse cria esse cargo um atributo da classe Funcionario, assim vc bastará passar esse valor para a classe.

Espero ter ajudado!

FucinonárioVendedor, FuncionarioGerente, FuncionarioProgramador, FuncionarioDiretor … , etc

São só variações do cargo, ok

Cria um atributo cargo e preencha com o cargo do funcionário.

A cada instância vc pode colocar um cargo diferente

Ficou claro? :shock:

Boa tarde a todos.

Dizia um poeta informático anônimo que a melhor maneira de implementar uma aplicação é fazê-la de forma simples.

E não vejo a necessidade de se criar uma classe Funcionário e dela criar 500 subclasses diferentes, só porque voce tem 500 cargos na Empresa.

A maneira mais correta, penso assim eu, que voce deve criar dentro do seu banco de dados uma tabela para cadastrar Funcionários, (Nome, Enderêço, Telefone, Salário, cargo e etc.) e uma outra tabela para cadastrar os 500 cargos existentes da sua Empresa.

A partir daí, voce vai criar sim, classes o qual eu costumo chamar de “Bean”, que são classes com getters e setters que tem como atributos uma estrutura da tabela do cadastro “Funcionário” e outro Bean (Classe) com a estrutura da tabela “Cargos” para poder trafegar esses Beans em rede, isto se a sua aplicação for Web, mesmo que seja Desktop, também nada impede de se criar os Beans. E pronto, nada mais.

Se voce ainda quiser fazer um ComboBox dentro da classe funcionário, basta criar uma instância da classe cargos, afim de apanhar todos os cargos da tabela cargos e popular um arraylist para o combobox no design do layout.

500 classes não, pow…
afinal, cargo não deixa de ser um componente da ficha do funcionário, ele deverá estar junto com os outros atributos, os de dados pessoais.

Abraço…

Engraçado, muita gente respondendo a mesma coisa e não foi ao mesmo tempo. Parece até que o GUJ tá com eco.

Antes de criar um atributo chamado cargo, pense no que o cargo influencia para o seu modelo de negócio. Por exemplo, se os dados gravados para um gerente forem muito diferentes dos dados gravados para um funcionário, talvez seja melhor você criar duas classes Funcionário e Gerente.

O fato é que se seus métodos começarem a testar o tipo de cargo antes de fazer as ações, então é sinal que ou você precisa criar uma nova classe, chamada Cargo, e transferir métodos para ela usando então polimorfismo, ou você deverá rever sua árvore para criar subclasses de funcionário.

Fique atento, se a cara dos métodos ficar assim:

public void processarAumento() { switch (cargo) { case GERENTE: calculaAumentoGerente(); break; case VENDEDOR: calculaAumentoVendedor(); calculaBonusVendas(); break; case PROGRAMADOR: int metasSprint = obterMetasBatidas(this); calculaAumentoProgramador(metasSprint); break; } }

Ou o equivalente disso com ifs, é um sinal claro de que você deveria ter criado subclasses e não um atributo. Só fique atento que as subclasses não precisam ser necessariamente de funcionário, e sim, pode ser que sejam de uma nova classe, chamada Cargo.

ViniGodoy
Engraçado, muita gente respondendo a mesma coisa e não foi ao mesmo tempo. Parece até que o GUJ tá com eco.

Boa noite a todos.

A meu ver, o cargo pode até influenciar o modelo de negócio, porém não deixa de ser atributo e não pode deixar de ser tratado como tal, isto pois, todo Gerente é um Funcionário, somente a recíproca não é verdadeira, pois criar as classes Gerente e Funcionário, cada uma no mínimo terá que ter o atributo cargo.

Apesar disto tudo, caso voce queira dar tratamento especial aos Gerentes, que afinal acho justo, nada impede de se limitar estes dados via ResultSet, através de instruções SQL com critério cujo cargo seja igual a Gerente, ai sim, talvez a criação das duas classes já citadas acima justificaria a criação das mesmas, porém fica a pergunta: não seria disperdício de recursos ? Já que voce poderia utilizar este ResultSet dentro de um método ? Sei que existe códigos que são indispensáveis para o bom desenvolvimento das regras de negócio, porém, se voce puder simplificar e enxugar o código, a sua regra de negócio terá uma performance muito melhor, além é claro, ficar mais fácil de entender na hora da documentação do projeto.