Lidar com a OO em Sistemas Comerciais

Olá sua o contexto de sua dúvida chamou minha atenção, porém não conseguir entender bem o problema! poderia dar mais detalhes para melhor compreensão?

Não está clara a questão.

Uma tabela que representa os cargos, deve significar que tu estas falando de uma tabela cargos que se relaciona com uma tabela funcionários. É isso? Ai o funcionário tem um cargo_id, que tem uma chave estrangeira com o id de cargo. Com isso, seria possível saber qual o funcionário e qual o cargo. É isso?

tabela funcionário:
id
nome
cardo_id - Foreign key para id da tabela cargo

tabela cargo:
id
descricao

Com OO, resolve-se isso criando um modelo da tabela funcionário que tenha o mesmo campo, cargo_id. Com ele, tu cria o objeto funcionário, e faz tuas lógicas.

Questões de autorização de modificação(só o RH pode editar), ou gerar um combobox com os cargos podem ser feitas de inúmeras maneiras, mas não tem relação direta com orientação a objetos.

Geralmente em sistemas comerciais, o usuário do RH é quem CADASTRA OS CARGOS, ou seja, terei linhas "tuplas" em uma TABELA NO BANCO DE DADOS representando os CARGOS ao invés de CLASSES.

Exemplo:

+----------+----------------------------+--------+--------+ |ID |NOME |BONUS |COMISSAO| +----------+----------------------------+--------+--------+ |1 |VENDEDOR |0.00 |10.00 | +----------+----------------------------+--------+--------+ |2 |GERENTE DE VENDAS |20.00 |0.00 | +----------+----------------------------+--------+--------+ |3 |ANALISTA DE SISTEMAS |0.00 |0.00 | +----------+----------------------------+--------+--------+

Motivo: Nenhum cliente ira ficar pedindo para a SOFT HOUSE criar uma nova classe representado o CARGO, ele mesmo "O cliente" que cadastrar. Pensando dessa forma, muitos dos comportamentos que existem nestes sistemas não haverá como usar a OO puramente.

Acho que entendi!

No seu bando de dados terá duas tabelas FUNCIONARIO e CARGO, uma relacionando-se com a outra.

Organização dos seus pacotes:

MODEL; -> Classes: Cargo e Funcionario.
VIEW; -> Classes ou páginas html(sistemas web);
CONTROLLER;-> Classes que irão realizar o CRUD (Create, Research, Update, Delete) de cada tabela ou criar um genérico que sirva para qualquer tabela.

Na Orientação a Objetos você terá duas classes da sequinte forma:

class Cargo{
private Long id;
private String nome;
.
.
// gets and sets
.
.
}



class Funcionario{
// Aqui esta o segredo! Você cria uma variável do tipo do tipo Cargo!

private cargo Cargo;
.
.
// gets and sets
.
.

}

No Pacote controle terá uma classe para o CRUD do Cargo, então você terá um método que busca todos os cargos cadastrados no banco.

Depois disso na VIEW de funcionário quando "alguém" estiver cadastrando um funcionário irá apenas aparecer uma lista de cargos que já foram cadastrados por uma pessoa do RH (no seu caso)

Assim estará usando O.O puro!

Sim, eu estava falando exatamente o que você comentou, agora quanto a aula de OO sempre é criada uma classe para cada departamento. Então, me expressei dessa forma para mostrar no meu entendimento que não será possível usar OO nestes casos.

Vejamos!

o exemplo que coloquei anteriormente foi para mostrar que sua questão era resolvida com Orintação a Objetos.

Agora você esta dizendo que não será possível usar oo neste caso (isso no seu entendimento)

Primeiramente tentei entender o problema!!! Agora quero entender a forma que você esta pensando, para afirmar que não será possível usar oo.

Lhe mostrei como faz em o.o, mostre-me porque não serve para resolver a questão!

A conversa ta Legal!

Em um sistema que usa OO, vão existir classes para os CARGOS cada uma com o seu devido comportamento.

Em um sistema comercial, vai existir uma classe chamada CARGO e todos os comportamentos devem ser tratada nessa classe, já que o cadastros dos CARGOS vão ficar a cargo dos usuário do sistema.

Oi, Veranildo

Não usar classes diferentes para representar cada cargo não significa que seu sistema não usa OO. A meu ver, usar OO significa modelar o problema usando o conceito de objetos para unir dados e comportamento. Agora, a forma como você vai fazer a modelagem, quais classes você vai criar e quais responsabilidades cada uma terá já é uma escolha sua.

Então na solução que o Admilson mostrou, criando uma classe Cargo, ele usou OO para resolver o problema; apenas modelou de um outro jeito, atendendo ao seu requisito de que os funcionários do RH da empresa criem os cargos.

Talvez a sua dúvida tenha surgido por esse exemplo ser sempre tão presente nos cursos de OO por aí. Mas são apenas exemplos de como você pode modelar um problema.

Espero ter ajudado! Abraços

Oi Luiz,

Se, todas as vezes que um novo cargo for criado eu tiver que alterar o sistema "Estou falando isso em relação a um sistema comercial onde o mesmo é distribuído por todo o país." será um trabalho imenso a atualização do mesmo nos clientes. Ou seja, não se trata de implementação ou de OO, é um caso atípico que em determinadas ocasiões não compensa o uso da OO "Não é bala de prata, como tudo na engenharia de software, depende!".