rs... agora estamos nos entendendo..
tudo bem, entao na criacao do objeto pessoa (ou em outro momento, se fo
utilizado um *lazy loading*), a funcao sobre a qual estavamos discutindo
busca os enderecos da pessoa e povoa a lista, que esta no objeto Pessoa.
rs...entao acho q estavamos falando a mesma coisa, apenas nao nos
entendendo direito.
Tudo bem, agora que concordamos nesse ponto, posso voltar a minha duvida
original (espero que possamos concordar nisso tbm!)
O objeto pessoa teria uma lista, dessa forma:
Type
TPessoa = Class(TObject)
Private
FCodigo : Integer;
FNome : String;
LstEndereco : TList;
Protected
...
Public
Constructor Create;
Property Codigo : Integer Read FCodigo;
Property Nome : String Read FNome Write FNome;
*Property Enderecos : TList Read LstEndereco Write LstEndereco;
* *Function ListaPessoas: TList; Virtual; Abstract;*
End;
O problema que eu vejo nisso é que ListaPessoas é uma TList, ou seja, uma
lista genérica.
Quando eu acessar Pessos.Enderecos, teria que fazer um typecast dos objetos
que estao nela, para obter o objeto do tipo Endereco.
E fazendo esse typecast, corro o risco de criar erros no sistema, já que
pode ser que em algum momento, por um engano, eu poderia colocar uma classe
de outro tipo na lista de enderecos, e o compilador nao acusaria nada.
O que poderia ser feito é uma lista especializada, que descenda de TList, e
trabalhe apenas com objetos do tipo Endereco.
Mas dai, nesse caso, eu nao poderia, na classe endereco, ter uma referencia
para a pessoa a qual pertence o endereco, na forma:
Type
TEndereco = Class(TObject)
Private
*FPessoa : TPessoa;*
Protected
pq dai aconteceria uma referencia circular, entre TPessoa e TEndereco.
Imagino que tu uses a TList generica, conforme o teu exemplo. Mas tu nao
acha que isso pode acarretar em erros no codigo?
Sds.
Francisco
On 11/17/05, Romario (Listas) <[EMAIL PROTECTED]> wrote:
>
> A classe endereço *NÃO* tem uma lista de todos os endereços existentes,
> ela tem um método que recebe um objeto Pessoa ou apenas o código dessa
> pessoa e efetua uma busca no banco para trazer o(s) endereço(s) que
> estiver(em) relacionado(s) à essa pessoa.
>
> Quem tem uma lista (apenas uma lista) com um ou vários objetos Endereco
> é o objeto Pessoa. Ele solicitou à classe Endereco que fosse ao banco de
> dados e trouxesse todos os endereços que estivessem relacionados com
> ela. A classe Endereco por sua vez, faz a solicitação à camada de
> persistência que busca os dados, lê cada um dos registros recuperados,
> cria um objeto para cada endereço encontrado e popula a lista.
>
> Nenhum objeto deve ter acesso aos dados de outro objeto que não seja por
> solicitação direta. A exceção só existe para atributos públicos. Ou
> seja, se você precisa saber o endereço da Pessoa, pergunte à ela que ela
> pergunta ao Endereco e ele repassa a informação.
>
> Ex.:
>
> {Isso será feito no Formulário (Depois de populado o objeto)}
>
> Endereco := Pessoa.lstEnderecos.Items[i];
>
> edtLogradouro.Text := Endereco.Logradouro;
> edtNumero.Text := Endereco.Numero;
> edtComplemento.Text := Endereco.Complemento;
> edtBairro.Text := Endereco.Bairro;
> ...
>
> Fiquei na dúvida do "... seu eu conhecer..." e vou deduzir o que seja
> para tentar explicar.
>
> Para saber o endereço da Pessoa você terá *OBRIGATORIAMENTE* que
> conhecê-la. Qual a finalidade de se ter um endereço cadastrado sem poder
> ter uma Pessoa associada à ele? Não existe, não é???
>
> Nesse caso, quem fará uso do "Class Function ListaEnderecos(oPessoa:
> TPessoa): TList;" é o objeto Pessoa quando for criado e populado.
>
> Me fiz entender dessa vez?
>
> Caramba!!! Onde estão os autores de livros, mestrandos, doutorandos e
> experts em orientação a objetos que não opinam nessa thread? :-D
>
> Sds,
>
> Romario
>
>
>
>
>
> Francisco Trindade escreveu:
> > rs...sim, estamos nos entendendo.
> > Mas o que eu acho é que pessoa tem uma lista de instancias de endereco a
> > que ela esta associada, e nao que ela tenha que buscar isso em algum
> lugar.
> > A diferenca que eu vejo em nossas visoes, é que a sua (pelo menos ate
> onde
> > eu entendi) assume a existencia de um banco de dados, ou outra forma de
> > persistencia, ou no minimo, que a classe endereco tenha uma lista com
> todos
> > os enderecos existentes (mas dai eu nao entendo como um objeto endereco
> tera
> > a lista de todos objetos endereco)
> > Outra questao que vejo é a seguinte:
> > No caso de endereco ser uma propriedade privada de Pessoa, entao nenhuma
> > outra classe, mesmo que conheca Pessoa, podera ter acesso ao endereco.
> > Do seu modo, seu eu conhecer Pessoa e Endereco, poderei chamar a funcao
> > Class Function ListaEnderecos(oPessoa: TPessoa): TList
> > que terei o endereco da pessoa.
> > Concorda?
> > Sds,
> > Francisco
> >
> >
> >
> > On 11/17/05, Romario (Listas) <[EMAIL PROTECTED]> wrote:
> >
> >>Ops! Agora estamos começando a nos entender. (rsrs)
> >>
> >>Se essa é a sua visão atual, você conseguiu entender o que eu tentava
> >>explicar.
> >>
> >>Pessoa "conhece" a(s) instância(s) de Endereco porque ela fez uma
> >>solicitação à classe e recebeu como resposta essa(s) instância(s).
> >>
> >>Uma instância do objeto Endereco *NÃO* conhece as outras instâncias da
> >>mesma classe porque não existe ligação entre elas. Isso é uma afirmação.
> >>
> >>É dessa forma mesmo que está entendendo?
> >>
> >>Sds,
> >>
> >>Romario
> >>
> >>
> >>
> >>
> >>Francisco Trindade escreveu:
> >>
> >>>rs.. nao sei, mas eu continuo com a minha opiniao.
> >>>Uma instancia do objeto endereco deve saber tudo sobre ele, como
> >>>rua,numero,complemento,etc..
> >>>mas quem conhece as instancias, sao os objetos que fazem uso delas, no
> >>
> >>caso
> >>
> >>>, a pessoa.
> >>>Mas uma instancia do objeto endereco nao deve conhecer as outras
> >>>instancias do mesmo, a nao ser nos casos necessarios.
> >>>Sds,
> >>>Francisco
> >>>On 11/14/05, Romario (Listas) <[EMAIL PROTECTED]> wrote:
> >>>
> >>>
> >>>>Francisco,
> >>>>
> >>>>A sua visão me parece estar um pouquinho distorcida. Ou será que é a
> >>>>minha??? (rsrs)
> >>>>
> >>>>Note que Endereco é um objeto e *TUDO* o que diz respeito à ele está
> >>>>dentro dele.
> >>>>
> >>>>Como sabemos que na OO as instâncias se comunicam através de
> mensagens,
> >>>>para que um objeto saiba alguma coisa a respeito de outro, ele
> precisará
> >>>>perguntar a esse outro.
> >>>>
> >>>>Trocando em miúdos, para que Pessoa saiba o endereço, ele precisará
> >>>>pedir ao objeto Endereco essa informação.
> >>>>
> >>>>Sds,
> >>>>
> >>>>Romario
>
>
>
>
>
> _______________________________________________________
> Yahoo! Acesso Grátis: Internet rápida e grátis.
> Instale o discador agora!
> http://br.acesso.yahoo.com/
>
>
>
> --
> <<<<< FAVOR REMOVER ESTA PARTE AO RESPONDER ESTA MENSAGEM >>>>>
>
>
>
>
>
> *Yahoo! Grupos, um serviço oferecido por:* PUBLICIDADE
>
> <http://br.rd.yahoo.com/SIG=12fn19l1c/M=380335.7481167.8369105.2369893/D=brclubs/S=2137111264:HM/Y=BR/EXP=1132261986/A=3126093/R=2/id=noscript/SIG=12c39trgo/*http://ad.br.doubleclick.net/clk;22846485;12120066;a?http://www.hoteis.com>
> ------------------------------
> *Links do Yahoo! Grupos*
>
> - Para visitar o site do seu grupo na web, acesse:
> http://br.groups.yahoo.com/group/delphi-br/
> - Para sair deste grupo, envie um e-mail para:
> [EMAIL PROTECTED]<[EMAIL PROTECTED]>
> - O uso que você faz do Yahoo! Grupos está sujeito aos Termos do
> Serviço do Yahoo! <http://br.yahoo.com/info/utos.html>.
>
>
--
--
Francisco Trindade
[As partes desta mensagem que não continham texto foram removidas]
--
<<<<< FAVOR REMOVER ESTA PARTE AO RESPONDER ESTA MENSAGEM >>>>>
<*> Para ver as mensagens antigas, acesse:
http://br.groups.yahoo.com/group/delphi-br/messages
<*> Para falar com o moderador, envie um e-mail para:
[EMAIL PROTECTED]
Links do Yahoo! Grupos
<*> Para visitar o site do seu grupo na web, acesse:
http://br.groups.yahoo.com/group/delphi-br/
<*> Para sair deste grupo, envie um e-mail para:
[EMAIL PROTECTED]
<*> O uso que você faz do Yahoo! Grupos está sujeito aos:
http://br.yahoo.com/info/utos.html
