Dúvida sobre OO na prática
07/12/2010
Sempre desenvolvi software em Delphi orientado a dados ou seja RAD, somente ligando os componentes não visuais de datasets a grids, dbedits etc, o sql ficava na tela mesmo e era montado dinamicamnete por opções que o usuário selecionava. Até ai era mil maravilhas.
Porém me deparei com a tal da escalabilidade e um software feito dessa forma não escala nem a pau. Foi quando resolvi me aprofundar em OO e UML. Gostei, comprei a idéia e até comecei a desenvoler dessa forma, mas eu não consegui resolver o pequeno problema que vai abaixo.
Digamo que numa folha de pagamento o usuário queira lançar uma falta e para isso ele deve selecionar um trabalhador, para facilitar o exemplo vamos dizer que haja uma caixa de combinação (combobox) com os únicos 10 funcionários da entidade não os 3mil que geralmente aparecem rsrsrs. Nesse caso haveriam 10 objetos do tipo TTrabalhador na memória com suas matriculas, nomes, datas de admissão etc.
O problema é que todo trabalhador tem seu cargo (que é um objeto), seu salário (que é um objeto), seu vinculo empregatício (que é um objeto), sua unidade de custeio (que é um objeto), e assim vai. Com isso quer dizer que para instanciar os 10 objetos do tipo TTrabalhador teria que antes ter listado na memória todos cargos, salários, vínculos, unidades de custeio, etc.!
É só isso que eu não consigo driblar.
Em RAD, só com SQL e dataset seria mais enxuto, ou seja, seria um sql simples sem nem fazer join com os cargos, salarios, etc, ou talvez apenas com vínculo que estaria resolvido, utilizaria os dados do dataset que eu quisesse e viriam do banco de dados apenas o necesário.
Obrigado pela atenção e desculpem qualquer coisa.
Higor
Posts
O grande problema do OO e ER é que a relação OO/ER não é 1:1, entende? Para fugir de armadilhas como essa que tu mencionou tu vai ter de recorrer ás PK's e FK's, mencionando um objeto dentro de outro, como por exemplo:
Objeto Funcionário:Int codigo_funcionário;String nome_funcionario;CentrodeCusto codigo_ccusto; <-- Objeto Centro de custoVinculoEmpregaticio tipo_vempregaticio <--Objeto vínculo empregatício
Objeto CentrodeCusto:int codigo_centro;String descricao_ccusto;String ativo;String data_criacao;
Objeto VínculoEmpregaticio:int codigo_do_vinculo;String descricao_vinculo;String tipo_clt;
Aí tu chama assim:
Funcionario.CentrodeCusto.ativo = tal valorFuncionario.VínculoEmpregaticio.codigo_do_vinculo = tal valor
Espero que tenha ajudado.
24/03/2011
André Silveira
Na realidade você não terá todos esses objetos criados na memória só para o cara selecionar, para ele selecionar pode até se ter um componente dataware (dbgrid) com a lista dos funcionários, após selecionado um funcionario que você vai criar o objeto funcionário e setar as suas propriedades, não precisa ter os objetos cargo, salario, departamento criados nesse momento, pois ao criar o objeto funcionário que vao ser criados esses objetos.
TFuncionario = Class
Depto : TDepartamento;
Salario : TSalario;
Nome : String;
Codigo : Integer;
end;
Essa é uma modelagem mais ou menos do que você teria na sua classe funcionário.
24/03/2011
Higor Granzoto
Agora estamos falando a mesma língua, perfeito, entendi, última dúvida:
Para eu levantar esse objeto na memória eu teria que fazer no mínimo três acessos ao banco, um para o funcionário, um para o departamento e outro para o salário. Correto?Só queria saber se isso é aceitável no mundo OO, pois comparando com o mundo dataware fiz dois acesso a mais, e não um só com dois joins.
24/03/2011
Gustavo Bretas
É ae pessoal.
Higor, vc manipula os objetos na sua classe direto na variável ou às encapsula? Eu fária da seguinte forma:
TFuncionario = Class
private
varDepartamento : TDepartamento;
varNome : String;
varCodigo : Integer;
public
function GetDepartamento : TDepartamento;
end;
...
function TFuncionario.GetDepartamento : TDepartamento;
begin
if not Assigned(varDepartamento ) then
varDepartamento := TDepartamento.Create;
Result := varDepartamento
end;
Ou seja ao invés de criar as variáveis no Create da classe, crie-as quando forem solicitadas.
Tem a opção de usar Property, mantem o princípio, e só vai mudar a declaração.
TFuncionario = Class
private
varDepartamento : TDepartamento;
varNome : String;
varCodigo : Integer;
function GetDepartamento : TDepartamento;
public
property Departamento : TDepartamento read GetDepartamento;
end;
Pensa aí... abraço!
24/03/2011
Higor Granzoto
Já considerei essa ideia tb, o problema é que se eu estiver num loop de 1000 TFuncionario e tivesse que ler alguma propriedade do departamento do funcionário atual eu faria 1000 acessos ao banco em centésimos de segundo só pra levantar o objeto TDepartamento de cada um separadamente, isso sem considerar que em 1000 TFuncionario pode ser que hajam 30 TDepartamento diferentes o que na pior das hipóteses seriam 30 acessos a toa, mas não serão pq a abordagem fará 1000 acessos, mesmo que aquele TDepartamento já tenha sido criado.
Mas tudo bem, só não sei se isso é aceitável no mundo OO, se é assim que se costuma fazer mesmo.
Use as classes TCollectionItem e TCollection para ter uma coleção de objetos.
De uma olhada nestes links:
http://leonardomopaca.wordpress.com/2009/06/01/colecoes-em-delphi-tcollection-e-tcollectionitem-parte-1/
http://leonardomopaca.wordpress.com/2009/06/02/colecoes-em-delphi-%E2%80%93-tcollection-e-tcollectionitem-%E2%80%93-parte-2/
Espero ter colaborado.
