Propriedades X Campos – Porque Usar Propriedades Ao Invés De Campos

Porque Usar Propriedades Ao Invés De Campos?

Já vimos o que são propriedades e campos de uma classe.

Uma propriedade encapsula um campo privado. Ou seja, o campo não pode ser alterado “de fora”. Devemos fazer isso através da propriedade, utilizando o get e set para ler e guardar informação, respectivamente.

 

E porque usamos propriedades ao invés de campos do tipo público?

 

Os getters e setters das propriedades podem incluir alguma lógica adicional, ao invés de simplesmente passar a informação de um lado para outro.

 

Veja um exemplo abaixo:

 

 

Bom, neste caso vemos claramente uma utilidade em utilizar uma propriedade para acessar um campo privado. Temos uma lógica a mais na hora de ler e guardar e informação no campo.

 

Mas, se não tiver nenhuma lógica especial no getter/setter, porque devo usar uma propriedade?

 

Propriedades X Campos – Porque usar propriedades ao invés de campos?

 

Aparentemente não há diferença entre isso

 

 

e isto:

 

 

Ambos irão expor o estado de um objeto ao mundo exterior e podem ser lidos/gravados da mesma maneira, com a mesma sintaxe. Existe alguma razão para utilizar uma propriedade, além do fato de ser considerado uma boa prática de programação?

 

Vamos enumerar algumas razões:

 

– Campos não podem ser usados em interfaces

 

Olha o erro que o Visual Studio te mostra quando você tenta usar um campo em uma Interface

Olha o erro que o Visual Studio te mostra quando você tenta usar um campo em uma Interface

 

Você não pode impor a existência de um campo no contrato público de um objeto através de uma interface. No caso de propriedades, isto funciona.

 

– Validação

 

Vamos supor que você está desenvolvendo uma API que não precise de nenhuma lógica de validação e você decida usar um campo público ao invés de uma propriedade.

 

Terminado o projeto, a aplicação sobe para a produção sem maiores problemas. Passado algum tempo, o cliente/usuário do sistema sente a necessidade de alterar um requisito do negócio. E agora será necessário incluir uma regra neste campo.

 

A esta altura do campeonato, alterar um campo para uma propriedade irá “quebrar” eventuais aplicativos que estiverem consumindo sua API. Será necessário alterar todos os “consumidores” da API, o que gera um bruta trabalho.

 

– Serialização binária

 

A “quebra” de objeto gerada pela alteração de um campo em propriedade também gera problemas na serialização binária.

 

Mas, o que é serialização?

 

A grosso modo, serialização é a conversão de um objeto em uma “tripa” de bytes. É utilizada principalmente para trafegar o objeto de um lado para outro (do servidor para o navegador do usuário, por exemplo). Desta forma, um objeto é transformado em uma sequência de bytes, pode ser enviado através da rede para outro lugar e em seguida é deserializado (é transformado novamente em um objeto), resultando em um clone do objeto original.

 

Não vamos entrar em detalhes da serialização binária, este é um assunto para outro artigo. Apenas tenha em mente que este é um dos motivos de utilizarmos propriedades ao invés de campos.

 

– A maioria dos objetos de ligação de dados (data binding) da infra-estrutura .NET faz a ligação (binding) através de propriedades, e não a campos

 

Há muita controvérsia se isso é o melhor método ou não, mas é assim que funciona.

 

– A exposição de um campo público é uma violação das Diretrizes da Microsoft para programação de código robusto e de fácil manutenção usando o .NET Framework

 

Palavras Finais

 

Este artigo ficou meio que “escovando bits” mas isso foi necessário para explicar os motivos de se usar propriedades ao invés de campos em nossos objetos.

 

Não se desespere se você não entendeu muito bem os motivos. Fique com a mensagem principal: existem razões técnicas para não utilizarmos campos do tipo público. Isso vai evitar algumas dores de cabeça no futuro.

 

E para receber um aviso quando os próximos artigos forem publicados, se cadastre na lista VIP do Celso!

Comece pelo e-book GRATUITO

5 Passos Para Ser Um App Dev

Se você não sabe por onde começar, este e-book te mostra os passos para ser um desenvolvedor de aplicativos de sucesso.
100% livre de spam.

Para enviar seu comentário, preencha os campos abaixo:

Deixe uma resposta

*

Seja o primeiro a comentar!