Fórum quala vantagem de usar property ao invés de function em poo? #295076

>> ´Pq a maioria´
Alguns. Tudo depende da necessidade.

A palavra de ordem é abstração.
Se a,b,c,d acessam Z, convém colocar um intermediário para que, ao mudar Z, o código não quebre. Fica assim:
a,b,c,d -> Y -> Z

>> ´usa um set como procedure e uma property para o get´
Por exemplo:
property Nome:string read FNome write SetNome;

SetNome geralmente é privado/protegido para que não seja acessado fora do escopo do objeto. Para que seu objeto não receba lixo você deve ser precavido e não fazer simplesmente ´write FNome´. E se o usuário do objeto atribuir um campo em branco ? caracteres inválidos ?

Por que ´read FNome´ e não ´read GetNome´ ? Depende da necessidade. Geralmente basta retornar o campo. Mas há casos em que você precisa executar mais operações: gerar um log, disparar um evento, setar outras variáveis...

Referências:
http://www.delphibasics.co.uk/RTL.asp?Name=Property

Rod.

Além do que o colega _rodfaria_ citou, acho que usar um property tem duas outras vantagens...

A primeira é transparência, porque posso mudar entre acessar diretamente a variável ou acessar via uma função que o resto do código não percebe a diferença.

A segunda é que o compilador pode otimizar o código gerado. Se ler a propriedade equivaler a ler uma variável, o compilador irá gerar código equivalente a ler uma variável.

Eu gostaria de participar deste topico com algumas dúvidas.

Eu estava lendo um livro de delphi , ha tempos atrás e como exemplo estava desenvolvendo um componente... O Autor me apresentou (ou pelo menos tentou me apresentar ) o conceito de propriedades e ele escreveu mais ou mesmos assim:



[b:e453bd5634]Com isso ele mudou de assunto e me deixou sem entender [/b:e453bd5634]nada :cry: :cry: :cry:

Eu não sei se qual a diferença prática das tres definiçoes :cry: :cry:



eu não sei se é a implementação desses métodos que definirão a Propreidades tem que ser obrigatoriamnete diferentes nas tres definiçoes acima , ou se a inclusão dos termos set e get são apenas simbogias para que outros programadores entendam a atuação desses métodos na definição dessas propriedades ....

Do ponto de vista de [b:c98edbd0e2]quem usa[/b:c98edbd0e2] essa propriedade, é indiferente como o acesso a ela é implementada (via função/procedure ou acesso direto). O que importa (para quem usa) é que podemos declarar um propriedade read-only ou write-only...

Do ponto de vista de [b:c98edbd0e2]quem implementa[/b:c98edbd0e2] essa propriedade, usar uma função/procedure para acessar o valor permite implementar validação ao atribuir o valor, formatação ao recuperar o valor, conversão de formato ou meio de armazenamento do valor (por exemplo, o valor armazenado poderia ser um TDateTime, mas a propriedade é um Integer).

[quote:c98edbd0e2=´Marco Salles´]eu não sei se é a implementação desses métodos que definirão a Propreidades tem que ser obrigatoriamnete diferentes nas tres definiçoes acima...[/quote:c98edbd0e2]Não entendi... poderia explicar melhor?

[quote:c98edbd0e2=´Marco Salles´]...se a inclusão dos termos set e get são apenas simbogias para que outros programadores entendam a atuação desses métodos na definição dessas propriedades ....[/quote:c98edbd0e2]Em parte. Isso é importante para o compilador saber qual código gerar quando uma propriedade é utilizada no código. Por exemplo, se um código se refere a propriedade Month, dependendo da definição da propriedade o compilador gerará código apropriado; imaginando que estamos atribuindo um valor a Month, se a definição for usar a procedure SetMonth, o compilador gerará código para por os parâmetros na pilha e chamar a procedure, senão irá simplesmente carregar o valor na variável correspondente; se não houver definição de um acessor write, então a propriedade é read-only e o compilador gerará erro de compilação.