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:

private int _meuCampo;

public int MinhaPropriedade
{
    get {
        return _meuCampo/2;
    }


    set {
        if (value > 100)
            _meuCampo = 100;
        else
            _meuCampo = value;
    }
}

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

public Property Nome() As String

e isto:

public Nome() As String

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

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.

Meu e-book Como Aprender a Programar do Absoluto Zero está GRATUITO por tempo limitado!

Olha o link: 👉🏼 http://celsokitamura.com.br/como-aprender-a-programar

Bora aprender a programar!