Java menos verboso com Lombok

Já vimos como não aprender Java e Orientação a Objetos. Aprendemos que a geração indiscriminada de getters e setters pode quebrar o encapsulamento de suas classes.

Quando há realmente a necessidade de alguns getters e setters, podemos gerá-los com o auxílio de nossa IDE preferida, inclusive é boa prática reescrevermos os métodos equals(), hashCode() e toString(). Vejamos um exemplo de uma simples classe com apenas 3 atributos:

import java.util.Calendar;

public class Contato {
	private Long id;
	private String nome;
	private Calendar dataNascimento;

	public void setId(Long id) {
		this.id = id;
	}

	public Long getId() {
		return this.id;
	}

	public void setNome(String nome) {
		this.nome = nome;
	}

	public String getNome() {
		return this.nome;
	}

	public void setDataNascimento(Calendar dataNascimento) {
		this.dataNascimento = dataNascimento;
	}

	public Calendar getDataNascimento() {
		return this.dataNascimento;
	}

	@Override
	public String toString() {
		return "Contato [id=" + id + ", nome=" + nome + ", dataNascimento="
				+ dataNascimento + "]";
	}

	@Override
	public int hashCode() {
		final int prime = 31;
		int result = 1;
		result = prime * result
				+ ((dataNascimento == null) ? 0 : dataNascimento.hashCode());
		result = prime * result + ((id == null) ? 0 : id.hashCode());
		result = prime * result + ((nome == null) ? 0 : nome.hashCode());
		return result;
	}

	@Override
	public boolean equals(Object obj) {
		if (this == obj)
			return true;
		if (obj == null)
			return false;
		if (getClass() != obj.getClass())
			return false;
		Contato other = (Contato) obj;
		if (dataNascimento == null) {
			if (other.dataNascimento != null)
				return false;
		} else if (!dataNascimento.equals(other.dataNascimento))
			return false;
		if (id == null) {
			if (other.id != null)
				return false;
		} else if (!id.equals(other.id))
			return false;
		if (nome == null) {
			if (other.nome != null)
				return false;
		} else if (!nome.equals(other.nome))
			return false;
		return true;
	}
}

Muita coisa, não?

Diminuindo a verbosidade

Temos um código funcional, porém extremamente verboso. Podemos evitar esta verbosidade tão comum em código Java com o auxilio do Project Lombok, que já foi comentado neste post sobre meta programação em Java. Vejamos o mesmo código reescrito utilizando Lombok:

import java.util.Calendar;

import lombok.EqualsAndHashCode;
import lombok.Getter;
import lombok.Setter;
import lombok.ToString;

@EqualsAndHashCode @ToString
public class Contato {
	@Getter @Setter
	private Long id;

	@Getter @Setter
	private String nome;

	@Getter @Setter
	private Calendar dataNascimento;
}

Utilizando a classe Contato:

Contato contato = new Contato();

// Como este setter apareceu?
contato.setNome("Flávio Almeida");

// E este getter?
System.out.println(contato.getNome());

// Imprimiu todos os atributos da classe!
contato.toString();

A mágica por trás do Lombok

Tudo isso é possível porque o Lombok integra-se tanto ao Eclipse quanto ao NetBeans. Quando a IDE compila suas classes, automaticamente é gerado o respectivo código Java para cada um das anotações utilizadas: @Setter, @Getter, @EqualsAndHashCode e @ToString, tudo através de Abstract Syntax Tree (AST).

Isso pode ser visto através da view de outline do eclipse:

outline-eclipse

Integrando o Lombok ao seu Eclipse/Netbeans e ao seu projeto

O lombok precisa ser instalado no Eclipse/NetBeans, o que é feito baixando o jar no site Project Lombok.

Ao executar o jar através do comando java -jar lombok.jar, um assistente perguntará o local da instalação da IDE e nada mais.

instalador-lombok

Por fim, como precisamos importar suas anotações, o jar deve estar no build path do seu projeto.

Conclusão

É possível escrever código Java menos verboso com auxílio do Lombok sem termos que esperar por modificações na linguagem. Existem outras anotações deste projeto que podem ser utilizadas para enxugar ainda mais o seu código.

Certamente uma extensão tão poderosa da linguagem pode também te trazer problemas: uma equipe nova pode demorar a se habituar, além de você ficar dependendo da ferramenta em relação a atualizações, bugs, etc. Mas com isso podemos ver que o Java pode sim ter um código mais conciso e sucinto.

47 Comentários

  1. José V. Dal Prá Junior 14/02/2013 at 10:36 #

    Ele também pode ser utilizado pelo Maven, Gradle ou direto pelo compilador Java.

    Não precisa ficar preso ao Eclipse. Isso ajuda em ambientes de integração e deploy contínuo.

    Valeu.

  2. Paulo Silveira 14/02/2013 at 10:40 #

    Pois é Junior, como linkado la no post de 2009, pelo uso do APT nao é necessario nenhuma ferramenta, ja que é padrão. É o mesmo recurso do static meta model da JPA

  3. André Vasconcelos 14/02/2013 at 13:11 #

    Realmente ficou muito melhor ter o codigo mais limpo.

  4. José V. Dal Prá Junior 14/02/2013 at 13:59 #

    Eu vejo que poderíamos ter mais frameworks de metaprogramação no Java. E ganharíamos mais produtividade a curto prazo.

    Mesmo em tempo de compilação, mais metaprogramação seria muito útil.

  5. José V. Dal Prá Junior 14/02/2013 at 14:06 #

    Ah … muito bom o artigo! Como sempre.

  6. Alexandre 14/02/2013 at 15:15 #

    Achei interessante, mas não vejo como tratar as pre-condições e isso também pode afetar também as invariantes de um objeto. Na maioria dos casos, um get deve verificar os dados de entrada, para que não sejam inválidos, como um nome nulo, e (em casos mais raros) o set não deve permitir que seja compartilhados dados que possam ser alterados como uma referência a uma lista em um VO por exemplo, no qual ele deve providenciar uma cópia ou uma lista que não pode ser modificada! A utilização seria ideal para TOs, mas o uso indiscriminado desses pode causar muitos problems!

  7. Flávio Almeida 14/02/2013 at 17:24 #

    Olá Alexandre, esta solução como você já notou não é bala de prata, mas funciona muito bem quando você precisa atender o padrão Java Bean para agradar determinado framework.

  8. Flávio Almeida 14/02/2013 at 17:28 #

    Olá Junior, realmente, o programador não fica amarrado a uma IDE, podendo escolher aquela que preferir.

  9. Victor Hogemann 14/02/2013 at 19:25 #

    Eu sou o único por aqui que acha que esse trauma de “o Java é verboso”, é fruto de uma época onde EJB1.x e Swing eram a regra?

    Grande parte dessa “verbosidade” vem também de um código mal estruturado, onde uma base mais bem pensada vai distribuir a complexidade utilizando recursos de OO como polimorfismo.

    Na boa que eu acho que essa galera que acredita que o Java é verboso demais na realidade acredita estar programando em Java, quando na realidade ainda está programando em C ou Pascal. Com classes monolíticas, e mentalidade de código estruturado.

    Resumindo, esse Lombok é uma solução em busca de um problema.

  10. Flávio Almeida 14/02/2013 at 23:31 #

    Olá Victor! Dentro do contexto do EJB, como você cita, o Java evoluiu bastante, principalmente com o EJB 3.0. O foco deste post não é a arquitetura de componentes no lado do servidor, mas a linguagem em si como foi ilustrado com o exemplo “antes” e “depois”. Abraço.

  11. Victor Hogemann 15/02/2013 at 09:32 #

    Mantenho minha posição,

    Getters e Setters, Equals e Hashcode são a única justificativa pra “verbosidade” do Java? Qualquer ganho que você possa ter usando esse Lombok vai pro vinagre a partir do momento em que você passe a construir seus beans utilizando modelo rico.

    E se você está utilizando um framework de persistência como o Hibernate, voce VAI querer ter todo controle possível sobre o comportamento do Hascode… geração automática pode ser perigosa, e a quantidade de annotations que você vai precisar colocar pra customizar o comportamento do Lombok provavelmente já vai deixar o código quase tão grande quanto o anterior, só que mais confuso.

    E se você precisa de Equals, principalmente quando está utilizando um modelo rico, provavelmente vai ter regras específicas de negócio… o mesmo vale pra quando seu modelo precisar implementar Comparable.

    O que eu quiz dizer ao citar aberrações como o EJB (sai-de-retro) é que dizer que o Java é verboso é propagar um mito. Se seus beans são grandes ao ponto dos getters e setters comprometerem a legibilidade do seu código, o problema não é da linguagem e sim do seu código: You’re doing it wrong. Your code is bad, and you should feel bad.

    Esse Lombok é pura maquiagem, e o efeito placebo que ele vai ter é muito mais perigoso que qualquer benefício que possa trazer.

    Enfim, uma solução procurando por um problema…

  12. Cirilo Lourenço Xavier Junior 15/02/2013 at 09:37 #

    Olá pessoal,
    já utilizei e ajuda bastante, mas faço minhas considerações:
    – Atenção ao utilizar o @ToString e @Data(que também gera o toString) pois se colocado, e acionados, em classes com referência cíclicas geram um loop infinito que acaba num StackOverflowError. Me deparei com esta situação em entidades com relacionamento bidirecional.
    – Quando utilizei o IntelliJ que não dava suporte para ele, mesmo utilizando o Maven para a integração contínua, a assistência de código na IDE ficou prejudicada.

  13. Flávio Almeida 15/02/2013 at 11:18 #

    Olá Cirilo! Valeu pela dica. Vou testar com o Lombok mais novo para ver se o problema permanece. Uma pena essa do IntelliJ, já que ele também é um excelente IDE. Abraço!

  14. Flávio Almeida 15/02/2013 at 12:16 #

    Olá Victor!

    Getters e setters são exemplos de verbosidade, principalmente quando você tem que atender o padrão Java Bean. http://en.wikipedia.org/wiki/JavaBeans

    A preocupação com o método HasCode(), ao meu ver, não é uma preocupação exclusiva do Hibernate, mas uma necessidade se voccê usa implementações de Set em Java. Para solucionar este problema ainda com Lombok, você pode fazer:

    @EqualsAndHashCode(exclude={“id”, “dataNascimento”})

    Não quero confundir a sintaxe da linguagem com a maneira como o código é organizado. Você pode ter um modelo rico, utilizar padrões de projeto e ainda sim ter seu código verboso.

    Uma das grandes promessas do Java 8 é justamente diminuir esta verbosidade. Este post exemplifica muito bem isso: http://blog.caelum.com.br/trabalhando-com-closures-no-java-8/

    Enfim, eu quero continuar criando um modelo rico, mas escrevendo menos.

  15. Ivan Sanchez 15/02/2013 at 13:55 #

    Me desculpe a ignorancia, mas quem precisa escrever tantos getters e setters a ponto que faz sentido adicionar mais uma dependencia somente para faze-los mais faceis de se escrever? Nao seria essa ferramenta apenas mais uma maneira de esconder codigo ruim debaixo do tapete?

    Fiquei curioso em saber como um “modelo rico” de verdade iria se beneficiar dessa abordagem….

  16. Paulo Silveira 15/02/2013 at 13:59 #

    tem razão dos getters e setters. mas acho que a ferramenta é mais interessante para os outros casos. como o hashcode e equals, ou qualquer outro caso de código que acaba sendo gerado automaticamente.

    de qualquer maneira, pessoalmente sou mais purista e evitaria esse tipo de mágica.

  17. Hugo Santos 15/02/2013 at 14:16 #

    Flávio, antes de mais nada, parabéns, ficou legal o artigo.

    Independente da critica acho importante entender a que o Lombok se propõe.

    É uma ferramenta para o desenvolvedor, que seja por motivos históricos (manutenção de código velho) seja por uma adequação a um padrão teria que de qualquer forma escrever os tais getters, setters, etc. Não vou entrar na discussão do que o programador ou o time poderia fazer, as refatorações, isso ou aquilo, estou assumindo a situação, está assim e tem que ser feito.

    Para uma aplicação vai ser desenvolvida agora e seguinto metodologias e práticas muito melhores, talvez não ajude tanto, mas quando estamos falando de “tem que fazer” não deixa de ser uma opção. Claro que devemos sempre ficar espertos com coisas como as que o Cirilo comentou e não adotar ferramentas que ainda estão instáveis pq aí a economia sai bem cara. Mas para um propósito bem específico, talvez valha a pena considerar.

  18. Ivan Sanchez 15/02/2013 at 14:39 #

    Para hashCode/equals eu ainda prefiro defini-los explicitamente. No maximo usando um Apache Commons para reduzir o boilerplate.

    Permitir algo como @EqualsAndHashCode(exclude={“id”, “dataNascimento”}) tambem introduz o risco ao adicionar um atributo novo, ja que este sera automaticamente incluido nestes metodos e a mudanca de comportamento provavelmente passara batida pelo programador. Ou seja, receita para dor de cabeca futura.

    Por isso tambem sou a favor de evitar esse tipo de magica…

  19. Paulo Silveira 15/02/2013 at 14:44 #

    Ivan, esse argumento é igualmente válido se voce escrever seu proprio equals/hashcode e, ao adicionar um novo atributo, esquecer de refletir isso no equals/hashcode (vale lembrar que nem toda alteracao de novos atributos precisam mudar nosso equals e nosso hashcode, depende do que voce considera equals no seu dominio).

    Isto é, voce pode errar exatamente da mesmissima maneira com ou sem lombok. E alias é frequente mesmo sem lombok.

  20. Guilherme Dio 15/02/2013 at 14:58 #

    Olhei o link do “Como não aprender Java” e percebi que posso estar do lado negro da força.

    Porque ultimamente eu estou com costume de criar classes no formato simples e puro de Javabean com todos os setters e getters, sem nenhuma regra de negócio e o mínimo possível de lógica nos sets,gets ou construtores.
    E posteriormente construo uma classe utilitaria para cada bean com as lógicas, por exemplo, no caso de uma conta de banco eu teria o seguinte formato:

    Conta.java
    ContaUtil.java

    ContaUtil é no padrão singleton: ContaUtil.getInstance(objetoDeConta);

    Com métodos para handle de negócios do tipo:

    instance.saca(valor);
    instance.isSaldoNegativo();

    Obviamente este método permite que outros programadores gerem códigos com o set direto de saldo, se não souber da classe Util…

    Mas consideram isso uma má prática ? Devo jogar no lixo esta metodologia ?

  21. Paulo Silveira 15/02/2013 at 15:11 #

    oi Guilherme

    Eu tomaria cuidado com essa abordagem. É o que o pessoal chama de anemic domain model. http://martinfowler.com/bliki/AnemicDomainModel.html

    Claro que há situacoes onde classes tem apenas getters e setters, mas elas deveriam ser bem mais raras do que costumamos ver por ai.

    Com o modelo anemico, voce começa a repetir codigo por ai, e mudancas na classe Conta acabam repercutindo nao so na ContaUtil, mas em todo mundo que acessa seus atributos quase que publicamente!

  22. Ivan Sanchez 15/02/2013 at 15:40 #

    Paulo, voce esta certo. Mesmo sem o lombok eh facil esquecer de revisitar equals/hashCode ao adicionar um atributo e em ambos os casos isso pode causar problemas.

    Mas por algum motivo ainda prefiro evitar esse tipo magica, principalmente quando ela modifica o comportamento do codigo sem uma intervencao direta do programador.

  23. Guilherme Dio 15/02/2013 at 17:08 #

    Realmente há seus pontos negativos, eu mesmo passei por situações adversas, e tive que criar certos workarround com wrappers, rs…

    Em alguns casos pode até chegar a funcionar do modo que eu possa ter previsto, mas em uma hora ou outra, os problemas veêm.

  24. Erick Massa Sprengel 16/02/2013 at 01:11 #

    Não gosto desta solução por acrescentar uma dependência a mais e pelos diversos problemas consequentemente gerados em cadeia.

    Mas pessoalmente eu acredito que o Java está fora da moda. A moda de simplicidade e menos codificação está na base das principais linguagens, frameworks e boas práticas que estão em ascensão. Exemplos como a linguagem Ruby e seu framework mais famoso, Ruby on Rails, estão cheios dessa nova onda.

    o termo Anemic Domain Model citado pelo Paulo deixa isso claro. É programar mais no model e deixar as classes de negócio mais enxutas, é o fat models and skinny controllers.

    Não vou discutir as inúmeras vantagens e desvantagens, mas para mim fica evidente que o Java não atende a esta moda. No entando o Java vai sofrendo suas “adaptações”, tanto na especificação (ou seja, “nativamente”), quanto através de frameworks como este, para seguir a moda.
    Não é só em relação a getter, setter, hashcode e toString. Vejo isso em todo canto, como nas interfaces, anonymous classes, inheritance, reflections… parece que a forma de tratar as classes e tipos são muito inflexíveis.
    O Java tem aquele estilo de deixar tudo para ser tratado pelo desenvolvedor, e isso é cheio de pontos positivos e negativos, mas também está fora de moda.

    Até que ponto o Java deve se adaptar a esta moda? Corre o risco de não se adaptar e morrer, se a moda não for moda (entende? rs). Ou o risco de se adaptar e no fim ficar algo “remendado” (sei que não é bem assim), perdendo definitivamente para as novas linguagens e seus frameworks.
    O Java não poderia traçar o seu futuro como uma linguagem C que tem as suas aplicações mais específicas, ao invés de ser “uma linguagem para tudo”?

    Sai um pouco do foco do post e fui para algo mais conceitual. #sorry

  25. Thiago Sampaio 18/02/2013 at 15:05 #

    Primeiro parabéns pelo post.

    Gente o lombok não veio pra simplificar absurdamente o seu código. Além desse projeto ter várias outras anotações interessantes como pro exemplo o @Cleanup onde basta vc anotar um recurso tipo Connection que ele vai se encarregar de fecha-lo caso ainda esteja aberto.

    Dentre as anotações a mais legal que acho é a @ExtensionMethod. Com ela vc consegue injetar dinamicamente métodos em qualquer classe nativa do java. Por exemplo, durante todo nosso código nos fazemos validações de todo tipo. Pra isso, copiando o Ruby/Rails que injeta na classe Object o método “blank” eu sempre que posso injeto na classe java.lang.Object o método “isBlank” e “notBlank”. Com isso eu posso fazer:

    “”.isBlank
    new Integer(“1″‘).isBlank
    pessoa.isBlank

    Além do mais no projeto lombok foi criado todas uma plataforma pra criação de suas próprias anotações de uma forma mais fácil.

    Por exemplo aqui no trabalho estamos tentando implementar em nossa anotação “@Repostiorio” para que assim que um modelo for anotado ele injet vários métodos como o Rails tipo: “findByNome()”

    Pra testar essa ferramenta criamos uma anotação “@Serializar”. Qualquer classe anotada com ela irá automaticamente implementar Serializable.

    Com essa ferramente vc pode criar várias coisas e quem sabe um dia teremos algo tipo o rails onde anotaremos um controller com “@Scaffold” e ele irá implementar todo o CRUD?

  26. Damiana Costa 19/02/2013 at 11:04 #

    Muito interessante…! Parabéns pelo artigo.

  27. Sidnei Carneiro 19/02/2013 at 11:13 #

    Olá Flávio, primeiramente parabéns pelo post.
    Gostaria de fazer um comentário, qual é realmente a necessidade desta lib? Pois só servirá para pojos simples isso é aqueles que não tem nenhuma programação em seus getters, setters, equals e hashs’s porém o próprio eclipse gera automaticamente, não seria desnecessário mais uma lib pendurada no projeto pesando-o?

  28. Bruno Bayma 19/02/2013 at 11:15 #

    A um tempo testei o lombok e aprovei.
    Comecei utilizando em projetos simples e funcionou muito bem, não resultou nenhum bug.
    É ótimo para utlizar com o padrão do java bean.
    Quando preciso de algo mais específico prefiro manter o padrão.
    Ajudou bastante a “limpar” o código.

    O lombok é uma ferramente bem legal, parabéns pelo post.

  29. Flávio Almeida 19/02/2013 at 12:35 #

    Olá Sidinei! Se você usar o básico do Lombok (as anotações que mostrei no post) ele nem precisar ir com seu projeto quando você realizar o deploy! Se você quiser usar outros recursos mais sofisticados que não abordei neste post, aí sim, o jar do lombok deverá estar presente no seu projeto.

  30. Sidnei Carneiro 19/02/2013 at 17:04 #

    Olá Flávio, obrigado pela resposta. Vou estudar mais sobre o Lombok, eu já tinha visto algumas coisas sobre ele e seu post me fez ter mais vontade de conhecê-lo.

    Abraços

  31. Marcus 19/02/2013 at 18:54 #

    Acho que o pessoal tem que cuidar com as generalizações. Não é porque fulano “nunca precisou disso” que beltrano “não deva usar”.

    Acho que o Lombok pode vir a ser muito útil, até porque um código enxuto pode ser inspecionado visualmente à procura de erros muito mais rapidamente.

  32. Giullliano 19/02/2013 at 22:54 #

    Nada contra o projeto em sí…mas numa boa….nossas classes hoje em dia tem mais anotação do que código escrito….

    Uma classe que seja mapeada pelo hibernate, use um validator, algumas coisas do maven, alguns elementos para gerar xml e ‘voalá’…uma dúzia de anotações por atributo

    é preciso discernir quando usar metaprogramação com anotações se torna realmente um benefício

  33. Rafael Simonelli 20/02/2013 at 00:13 #

    Sinceramente não vi ganho nenhum nos getters e setters, que geralmente são gerados automaticamente pelas IDEs (isso quando são gerados, vide artigos da própria Caelum não recomendando essa prática).

    Para ToString e Hashcode a mesma coisa se sua IDE permite configurar esse tipo de padrão gerando código com o Apache Commons.

    Mas esse framework me ganhou no Extension Method… vou ter que conhecer!

  34. João Paulo Faria 20/02/2013 at 12:28 #

    Grande Flávio,

    Parabéns pelo post. Eu utilizo o Lombok e acho muito legal. Não entendo pq tanta crítica, basta utilizar quando for necessário.

    Abs.

  35. David Paniz 20/02/2013 at 12:45 #

    Boa Flávio!
    Só pra deixar minha opinião… EU não gosto muito dessa abordagem.
    Se o problema é só escrever, a própria IDE gera getter, setter, equals e hashCode. Além de ser uma dependencia a mais no projeto, ainda gera uma “diferença” entre o fonte e o bytecode que pode te fazer perder um tempo tentando entender o que está acontecendo depois de um tempo.

  36. Claudemir 21/02/2013 at 09:19 #

    Gostaria de perguntar a respeito dos getter e setters quando seu um framework como o JSF, ja que o mesmo vai procurar pelos getters e setters…

    Como retirá-los então e não ter um modelo anêmico desta forma?

  37. Santos 21/02/2013 at 09:41 #

    Funciona com android? se sim como posso configurar?

  38. Clayton K. N. Passos 22/02/2013 at 14:17 #

    Legal, isso funciona sem IDE?
    Funciona em um projeto “Mavenizado”?

  39. Flávio Almeida 23/02/2013 at 00:16 #

    Oi Clayton! Funciona sim! http://projectlombok.org/mavenrepo/index.html

  40. Flávio Almeida 23/02/2013 at 00:17 #

    Santos! Funciona com android sim! A configuração é a mesma: integrar lombok com eclipse e colocá-lo no build path.

  41. Marcus 25/02/2013 at 13:42 #

    Ah, lembrei de outra coisa!

    Às vezes queremos criar getters e setters úteis (em vez dos triviais), mas somos “traídos” por um framework que chama getters e setters indiscriminadamente, várias vezes por requisição, supondo que eles não seriam custosos.

    Aí você põe o negócio pra rodar e então consultas, ordenamentos ou outros procedimentos executam múltiplas vezes por causa do framework. O programador acaba precisando voltar aos getters e setters triviais (colocando a lógica em outro lugar) para o programa se comportar de maneira decente… E voltamos à estaca zero. Por isso o Lombok me parece bem útil.

  42. kleber 04/06/2013 at 17:51 #

    tentei utilizar o lombok em um projeto antigo com JSF1.2 e, apesar da IDE não reclamar na utilização, durante o funcionamento com a aplicação levantada no tomcat, os gets, sets e cia não foram encontrados…

  43. Rodrigo 27/08/2013 at 12:15 #

    Consegui instalar com o Eclipse, mas com Netbeans não encontra o IDE installation. Sistema Operacional Win7 Professional. Alguma dica?!

  44. Fábio 13/07/2016 at 19:41 #

    Na minha opinião, em java, poderia ter uma melhor opção de get e set tal qual ocorre em C#.

    Pois quando você coloca a propriedade em private, você não quer que o usuário da classe altere a propriedade diretamente, isto se chama encapsulação, se alguém já estudou programação orientada a objetos, sabe que estou dizendo.
    Isto de encapsulação é bom para validar dados, antes de serem atribuidos a um propriedade.

    Por exemplo, na classe Quadrado abaixo, o método setLado, simplesmente, atribui o valor diretamente ao campo private lado, ou seja,
    não há nenhuma validação.

    public class Quadrado {
    private int lado;

    public int getLado(){
    return lado;
    }

    public void setLado(int value){
    lado = value;
    }

    }

    Em C#, esta mesma classe é escrita desta forma, quando não há nenhuma regra de validação.
    Em C#, chama-se propriedade auto-implementada.

    public class Quadrado {

    private int lado { get; set; }

    }

    Ou seja, observe que não há nenhuma validação, no código acima, se houver, ficaria desta forma:
    public class Quadrado {
    private int lado;
    public int lado {
    get {
    return lado;
    }
    set {
    if(value > 5)
    lado = 5;
    else
    lado = value;
    }
    }
    }

Deixe uma resposta