Getters e Setters via Reflection

Você pode criar uma linguagem chamada Java+P (Java + Properties) e um compilador para ela, gerando .class; infelizmente, reflection ou AOP não é capaz de mudar a sintaxe da linguagem. Nem mesmo annotations são capazes de fazer isso.

Inscreva-se no Sun Developer Network e vote neste bug:

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4228585

Ele tem 13 votos apenas, quando passar de 100 eles vão começar a levar em consideração. Junte seus amigos e colegas para que eles votem também

Qual o problema de clicar com o botão direito na sua classe e mandar ele gerar os getters e setters?!? Qualquer IDE que mereça respeito faz isso hoje em dia…

rodrigoallemand, leia o link que o thingol postou, lá tá melhor explicado…

Acabei de ler o link… realmente seria melhor se houvesse uma estrutura como a citada no exemplo. O código ficaria mais claro e objetivo, ao meu ver.

Vc usa alguma IDE ??? Vc já viu as opções de reatoração da IDE ??? Que problema que vc esta vendo, isso é falta de costume apenas !

Já tinha lido o tópico antes de postar e continuo com a minha opinião… qual o problema em gerar geters e setters?!? No final, vamos acabar escrevendo a mesma coisa, do mesmo jeito…

E seguindo o exemplo… qual a diferença de leitura?!?

// get the color
   c = obj.getColor();     // before
   c = obj.color;          // after

   // assign a new color
   obj.setColor(Color.red);  // before
   obj.color = Color.red;    // after

A leitura é a mesma de um atributo publico!!! Encapsulamentoi por encapsulamento, fazer um set e um get “in-line”, ou seja, direto, não me diz nada…

Acho que pensar um pouco em um modelo de como fazer os get/set via reflexão é melhor do que mudar a linguagem…

Se for pra copiar alguma coisa do .NET, que sejam as regions… isso sim ajudaria bastante a leitura dos códigos!!!

Acho que a melhor maneira de fazer isso seria criando alguma palavra reservada que não necessitasse de criação de um metodo pra get/set… tipo um…

//Antes private String nome; //Assim, ele automaticamente disponibilizaria acessos aos métodos getNome e setNome(String nome) //Caso vc precisasse fazer alguma alteração diferenciada, overflow!!! private getter setter String nome; private getter String sobrenome; //Neste casso só criariamos o getNome()

Já tinha lido o tópico antes de postar e continuo com a minha opinião… qual o problema em gerar geters e setters?!? No final, vamos acabar escrevendo a mesma coisa, do mesmo jeito…

E seguindo o exemplo… qual a diferença de leitura?!?

// get the color
   c = obj.getColor();     // before
   c = obj.color;          // after

   // assign a new color
   obj.setColor(Color.red);  // before
   obj.color = Color.red;    // after

A leitura é a mesma de um atributo publico!!! Encapsulamentoi por encapsulamento, fazer um set e um get “in-line”, ou seja, direto, não me diz nada…

Acho que pensar um pouco em um modelo de como fazer os get/set via reflexão é melhor do que mudar a linguagem…

Se for pra copiar alguma coisa do .NET, que sejam as regions… isso sim ajudaria bastante a leitura dos códigos!!!

Tirando a parte da region eu concordo com o Rodrigo. O legal das “properties” quando programava em C# era o tempo que ficava perdendo pra descobrir se era propriedade mesmo, se era variavel, se era constante … ao declarar uma constante publica, vc acessa da mesma maneira que as propriedades, e o legal é que cada programador c# programava da sua maneira, então tinha constantes em minusculas em algumas classes, outras em maiusculas, outras começando com a primeira letra em maiuscula … bom, já deu pra entender a alegria que era … Resumindo, acho bem melhor que exista um padrão para encapsular propriedades do que ter uma palavra chave somente e ocorrer a festa que descrevi acima.

Sobre region, essa era outra coisa que me fazia passar raiva … o uso de region é legal, o problema que o pessoal abusava muito dela. Por exemplo, ao abrir uma classe X vc já encontra logo de cara 3 regions, uma de declaração de variaveis, outra pra metodos, outra pra pogs … e assim vai. Até ai tudo bem, acho besteira isso mas tudo vc pode relevar. O problema era ao abrir um metodo ele tinha 15 linhas, depois de ir abrindo as regions, isso mesmo regionS (ate region dentro de region) você descobria que o método era um dinossauro de sei lá mais de 300 linhas …

Como falei, region é legal, mas o pessoal abusava tanto, que ele mais atrapalhava do ajudava.

fica ai o meu relato, é apenas a minha opinião, entendo a opinião de quem vai defende-las.

[]s,
Roger Leite

O problema ai era da sua equipe, e não das regions…
Acho que o uso correto de regions iria ajudar bastante na visualização do código, como por exemplo, criando-se uma region com os getters e setters…

Roger-- boa tarde:

Acho que o fato de tantas linguagens utilizar getter e setter transparentes para o desenvolvedor já é um motivo para ser considerado. Não estamos falando da visibilidade do lado de quem CRIA um componente, mas sim, a visibilidade do lado de quem USA o componente. Encapsular um código também envolve ocultar métodos internos que não interessam a quem está utilizando um objeto. Acho que esse é o caso dos getters e setters. Precisavamos ocultar a validação das propriedades… todo programador de outra linguagem sabe que se preencher um valor indevido para uma propriedade o sistema vai reclamar… mas não é essa a questão fundamental!!! Nem o fato de preguiça em digitar cada setter e getter.

A questão fundamental é: Tendo uma forma pré-definida de criar propriedades de forma transparente conforme o nosso amigo “cleiton herrmann” citou como exemplo, as IDEs poderiam nos avisar se uma propriedade é somente leitura, somente escrita, sem o desenvolvedor precisar ficar catando as funções get_isso e set_aquilo.

Já que isso o java não tem nativamente, pelo menos que seja possível via reflexion, pois assim poderia ser criado uma classe para extender essa funcionalidade para um sistema inteiro. Inclusive uma coisa interessante que eu vi no PHP, é que é possível interceptar qualquer método ou propriedade que não exista numa classe e redirecioná-lo para um tratamento dentro desta… Isso é um exemplo de como programação de alto e baixo nível está presente na linguagem, nativamente, dando total liberdade ao desenvolvedor e de forma transparente para quem utiliza.
Eu não consigo entender como uma linguagem como o Java, que possui até programação orientada a aspectos, não tenha esse recurso extendido de propriedades.

marcoex:

Já que isso o java não tem nativamente, pelo menos que seja possível via reflexion, pois assim poderia ser criado uma classe para extender essa funcionalidade para um sistema inteiro. Inclusive uma coisa interessante que eu vi no PHP, é que é possível interceptar qualquer método ou propriedade que não exista numa classe e redirecioná-lo para um tratamento dentro desta… Isso é um exemplo de como programação de alto e baixo nível está presente na linguagem, nativamente, dando total liberdade ao desenvolvedor e de forma transparente para quem utiliza.
Eu não consigo entender como uma linguagem como o Java, que possui até programação orientada a aspectos, não tenha esse recurso extendido de propriedades.

Sobre reflection, vc consegue fazer se vc passar o nome da propriedade para um método. Com isso vc consegue fazer um Set. Cria-se um objeto unico com esse método de Get/Set via reflection e todos os seus objetos extendem dele… Iria ficar ridiculo, mas iria funcionar…

E sobre ter ou não propriedades, questão de escolha!
Porque não ter herança multipla? Sobrecarga de operadores? Ponteiros?
Cabe, como o thingol falou, vc votar para que o seu pedido seja feito numa proxima versão de Java…

Obrigado Rodrigo. Tem algum exemplo ou site onde você já viu isso?

sei lah pessoal, na minha opiniao, os getters e setters ja estao consolidados, e a grande maioria das pessoas ja esta acostumada com eles…

no caso da classe XYZ do link citado no topico acima, eu acho q o codigo ficou bem mais estranho, do q com os getters and setters, mas na outra classe ateh q ficou bom usar apenas Objeto.atributo; para obter o valor dele.
Mas o metodo q retorna este valor teria q ser escrito igual, ateh mesmo pq de algum lugar tem q sair o retorno.

Na minha opiniao acho desnecessário essa mudanca, nao troco os getters e setters…

Não vi isso em lugar nenhum não… pensei rápido aqui comigo…
Se vc criar um objeto que tenha um método setProperty(String field, Object value) e um método getProperty(String field) vc consegue fazer qualquer get/set via reflexão. É só vc fazer os herança entre todos os seus objetos.
Nesse método setProperty, antes, vc deveria alterar a visibilidade do atributo e setar na mão o valor… acho que tem como fazer isso… tenho quase certeza…
Mas, eu acho que iria ficar feio demais…

ao q o nosso amigo " rodrigoallemand " disse, tem como sim, eu uso em um dao generico em uma aplicacao q estou desenvolvendo, e ja pensei em fazer um get e um set generico tbem, mas acho meio esquisito, e alem de alterar a visibilidade e acessibilidade do atributo e setar na mão o valor, vc teria que ter um if, um nao, um monte de if aninhado pra verificar o tipo do atributo q vc quer setar, int, float, double, string, date, enfim, para fazer a conversao dele antes de atribuir no objeto especifico, no meu dao, eu criei um unico metodo pra fazer isso, de forma q os metodos de consulta, retornem os valores e chamem esse metodo para preecher o objeto com os valores.

mas na questao dos get e set eu achei q ficaria meio esquisito, iria economizar codigo, mais ficaria esquisito um treco desses. levando em consideracao, botao direito, generate getters and setters, eu acho melhor. diferente do dao, que envolve uma logica maior e ficar reescrevendo sempre o mesmo codigo seria ruim.

Não li todos os tópicos mas não vejo nenhuma necessidade disto. Seriam mais palavras reservadas (property get set), mais uma forma de fazer a mesma coisa, mais sintaxes para decorar/aprender :evil: .

Testado e funcionando!!!

public class GetSetObject<Type> {
	
	private Class<Type> type = null;
	
	public GetSetObject(Class<Type> type){
		this.type = type;
	}
	
	public void setProperty(String field, Object value){
		try {
			Field attribute = type.getDeclaredField(field);
			attribute.setAccessible(true);
			attribute.set(this, value);
		} catch (Exception e) {
			throw new RuntimeException("Deu merda!");
		}
	}
	
	public Object getProperty(String field){
		try {
			Field attribute = type.getDeclaredField(field);
			attribute.setAccessible(true);
			return attribute.get(this);
		} catch (Exception e) {
			throw new RuntimeException("Deu merda!");
		}	
	}

}

public class MeuObjectSemGetSet extends GetSetObject<MeuObjectSemGetSet>{

	private String meuAtributo = null;
	
	public MeuObjectSemGetSet() {
		super(MeuObjectSemGetSet.class);
	}

}

public static void main(String[] args) {
	MeuObjectSemGetSet meuObjeto = new MeuObjectSemGetSet();
	meuObjeto.setProperty("meuAtributo", "Teste");
	System.out.println(meuObjeto.getProperty("meuAtributo"));
}

Li e reli o Bug, mas não encontrei a mínima utilidade disto.
13 votos em 8 anos, não dá nem 1 votos a cada seis meses, acho que não é só eu que não ve utilidade nesta feature proposta

"rodrigoallemand " boa ideia indexar o objeto Class, nao tinha pensado em usar dessa maneira, eu uso um if com instanceof para cada tipo de objeto que uso e entao atribuir o valor a ele, mas gostei da sua implementacao, acho q vou dar uma reavaliada no meu codigo, num pensamento rapido aqui acho q ficaria melhor indexar…

mas eu ainda nao troco os famosos get e set, por essa “nova forma” de se setar e obter os valores de um objeto, hehehhe

eh “xandroalmeida” eu tbem faco parte da grande maioria que nao ve utilidade nisso, uihauihauhiha

cleiton herrmann:

"rodrigoallemand " boa ideia indexar o objeto Class, nao tinha pensado em usar dessa maneira, eu uso um if com instanceof para cada tipo de objeto que uso e entao atribuir o valor a ele, mas gostei da sua implementacao, acho q vou dar uma reavaliada no meu codigo, num pensamento rapido aqui acho q ficaria melhor indexar…

mas eu ainda nao troco os famosos get e set, por essa “nova forma” de se setar e obter os valores de um objeto, hehehhe

eh “xandroalmeida” eu tbem faco parte da grande maioria que nao ve utilidade nisso, uihauihauhiha

Eu fiz isso só pra matar a curiosidade de como seria uma classe sem get/set… e eu tambem não troco os métodos por essa “gambi” criada por mim… tambem faço parte da maioria que não vê utilidade nisso…

sim sim eu intendo, tbem matou a minha curiosidade, pra falar a verdade eu ateh gostei dessa classe q tu fez, nao seria necessario escrever tantos gets e sets, mais fica esquisito usar dessa maneira neh, foje do padrao…

meuObjeto.setMeuAtributo("Teste");
meuObjeto.setProperty("meuAtributo", "Teste");

meuObjeto.getMeuAtributo();
meuObjeto.getProperty("meuAtributo");

nos beans ficaria legal, ateh me deu vontade de usar, mais nas classes da view fica muito fora do normal…

se fosse pra pensar em questao de sintaxe semi-inutil o foreach nao teria entrado só na versão 1.5, nem aqueles parametros estranhos com reticencias. Nao dá pra olhar pra essas coisas com preconceitos do tipo “po… isso eh preguiça de programador, tao facil apertar create setters and getters na ide”… mas pensa bem, e se nao existisse a ide? vc faria tudo na mão ou pior, faria com a gambeta do rodrigoallemand ali em cima.
Se existe esse tipo de propriedade transparente em várias linguagens não é por questão de sintaxe de preguiça, é por necessidade.

Quanto a vc estar lidando com um campo ou propriedade ou enum, code convension existe pra essas coisas, ou em java seria realmente possivel aproveitar o poder dos getter e setters sem reflexao utilizando convensões? Alem de que utilizar um campo diretamente é questionável em se tratando de OO.

mais uma coisinha…
e as eventuais validações q sao feitas nos metodos get e set
ex: um objeto soh pode receber um determinado valor se for de um tipo especifico

public void setCliente(Object obj) {
    if (obj instanceof Cliente) {
        cliente = (Cliente) obj;
    }
}

teriamos q fazer isso em outro lugar, talvez na view sei lah, ou ainda usando a “gambeta” generica do nosso amigo “rodrigoallemand” teriamos q encapsular as varias validacoes dentro desse unico metodo agregando varias coisas especificas em um treco generico, muito ruim nao??

cleiton herrmann:

mais uma coisinha…
e as eventuais validações q sao feitas nos metodos get e set
ex: um objeto soh pode receber um determinado valor se for de um tipo especifico

public void setCliente(Object obj) {
    if (obj instanceof Cliente) {
        cliente = (Cliente) obj;
    }
}

teriamos q fazer isso em outro lugar, talvez na view sei lah, ou ainda usando a “gambeta” generica do nosso amigo “rodrigoallemand” teriamos q encapsular as varias validacoes dentro desse unico metodo agregando varias coisas especificas em um treco generico, muito ruim nao??

Calma, gente… eu NÃO UTILIZO ISSO! EU APENAS CRIEI PARA VER COMO FICARIA! NÃO VÃO FALAR POR AI QUE O rodrigoallemand FAZ GAMBIARRAS DESSE TIPO, HEIN!!! :lol: :lol: :lol:

Putz… acho que ainda não é isso…

As propriedades são chamadas assim em outras linguagens (C# no exemplo):

PersonAge person = new PersonAge (); 

person.humanAge = 50; 
teste = person.humanAge; 


public class PersonAge { 
    private int _humanAge; // private local variable 

    public int humanAge 
    { 
        get //get accessor method 
        { 
            return age; 
        } 
        set //set accessor method 
        { 
            age = value; 
        } 
    } 
}

e não assim:

person.setProperty("humanAge", 50);
teste = person.getProperty("humanAge");

Dessa forma até eu preferiria usar getIsso e setAquilo normalmente… ehehehehe ;-}

hauihauihauiah, "rodrigoallemand " quanto a mim tu pode ficar tranquilo, eu nao to falando q ela eh ruim nao, ja ateh falei q gostei da “gambizinha” hehehee a gtn sabe q foi soh pra exemplificar

marcoex:

Putz... acho que ainda não é isso....

marcoex:

As propriedades são chamadas assim em outras linguagens (C# no exemplo):

PersonAge person = new PersonAge ();

person.humanAge = 50; 
teste = person.humanAge; 

public class PersonAge { 
    private int _humanAge; // private local variable 

    public int humanAge 
    { 
        get //get accessor method 
        { 
            return age; 
        } 
        set //set accessor method 
        { 
            age = value; 
        } 
    } 
}

e não assim:

person.setProperty("humanAge", 50);
teste = person.getProperty("humanAge");

Dessa forma até eu preferiria usar getIsso e setAquilo normalmente.... ehehehehe ;-}

public class PersonAge { 
    public int humanAge; // public local variable 
}

PersonAge person = new PersonAge ();

person.humanAge = 50; 
teste = person.humanAge;

public class PersonAge { 
    private int humanAge; // private local variable 

    public int getHumanAge(){
        return this.humanAge;
    }

    public void setHumanAge(int humanAge){
        this.humanAge = humanAge;
    }
}

PersonAge person = new PersonAge ();

person.setHumanAge(50); 
teste = person.getHumanAge();

rodrigoallemand:

Encapsulamento?!?!?!?
Pra que “encapsular” o que todo mundo sabe o que vai ser feito?!?!?
E por que não ter o get/set?!?

marcoex:

Pessoal, é um prazer participar pela primeira vez deste conceituado fórum.

Gostaria de fazer uma pergunta, levantando novamente a questão dos getters e setters. Todos nós sabemos a importância do encapsulamento e da utilização dos patterns da linguagem para boas práticas de desenvolvimento, mas gostaria expressar o meu desapontamento de no java não existir uma forma nativa de definir os getters e setters transparentemente, como em outras linguagens como javascript, visual basic, c#, php, etc etc etc.

Será que existe alguma forma de fazer isso em java nem que seja com reflection?

Na linguagem java não ( ainda , e espero que nunca haja) na plataforma java sim : Groovy.

O que vc quer é o conceito de propriedade e features de linguagem que dê suporte a isso.
Mas java é uma linguagem simples , sem esses manbo-jambos de linguagem “user frendly”
Eu já usei VB e acho um saco e verborraico. Java é mais básico, mais simples.

Groovy aumenta a sintaxe java padrão para se aproximar mais de uma linaguagem script
e uma das coisas que ele faz é dar suporte ao conceito de proptiedade. Vc pode fazer pessoa.nome = “João”.
mas no fim, ele invoca pessoa.setNome(“João”) e portanto Pessoa tem que ter get/setNome. Se vc olhar com atenção vc vai reprar que a sintaxe
java para propriedades é mais simples que NET ou VB porque é menos verborraica porque é baseada em convenções Afinal porque é preciso a palavra property em VB ? para nada, só para destinguir de um metodo normal. Em java essa diferença não existe.

Se vc que usar pessoa.nome = “João” , use groovy. Se vc quer uma forma dofernete de definir as propriedades, entenda que a do java é a mais simples.

Entendi… Muito obrigado a todos

O próprio ruby já faz isso com a keyworld attr_acessor, porém acho que durante a implementação eles acharam que o Java ficaria melhor usando o getters e setters como padrão e não algo implícito dentro da linguagem.

Normalmente eu tenho duas a três camadas de validação antes desse set ser feito.
Então, validação… aha… não é o meu caso e mesmo assim acho que regra de negocio de validação pode ser um método separado, e não em cadas set, descentralizando a sua regra de negocio.