Francisco,

Pelo que estou entendendo, você não precisará fazer um typecast do 
objeto. Só precisará recuperá-lo na lista, como informei anteriormente.

Ex.:  Endereco := Pessoa.lstEnderecos.Items[i];

O typecast seria :  Endereco := TEndereco(Pessoa.lstEnderecos.Items[i]);

Obs.: Não tenho como testar aqui, mas acredito que não seja necessário.

Quanto ao erro, acho que é impossível de acontecer porque a lista é 
criada, populada por um único tipo de objeto e destruída após a 
utilização. Não vejo porque você adicionaria tipos diferentes de objetos 
na lista.

Ainda não entendi porque você faz tanta questão que a navegabilidade 
esteja nos dois sentidos. Para que um Endereco ia querer saber a quem 
ele pertence?

Sds,

Romario




Francisco Trindade escreveu:
> 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

        

        
                
_______________________________________________________ 
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 >>>>>

<*> 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

 


Responder a