Li o artigo “Fantoches”, do pcalcado no wikipedia. Faz muito sentido.
Entretanto, uma frase me deixou um pouco confuso. Ele pergunta o seguinte no artigo: “… (afinal, o que são get e set além de um jeito mais lento de fazer um atributo público?)…”
Nao concordo muito com essa afirmação. Por exemplo, eu poderia ter o seguinte método na minha classe “Individuo”:
public void setDataNascimento(Timestamp data) throws Exception {
if ( data.after( Utilities.dataAtual() ) {
throw new Exception("Data nao pode ser superior a data de Hoje.");
}
}
que é um dos propósitos de metodos set, na minha opiniao.
O que eu axo totalmente desnecessario mesmo seria algo do tipo:
public void setDataNascimento( Timestamp data ) {
this.dataNascimento = data;
}
muito legal o topico, mas mesmo o mais basico como:
public void setDataNascimento( Timestamp data ) {
this.dataNascimento = data;
}
não seria inutil, não consigo ver outra forma de encapsular isso. Ja imaginou a zona que seria se os atributos fossem publicos, todo mundo metendo a mão. Bom sei lá, fala ai galera…
para linguagens que não tem refletion para ser utilizado em automatizadores como por exemplo em dispositivos que serializam informação, mas uso mais como um padrão de desenvolvimento e as vezes fasso coisas sem sentido como foi exposto pelo amigo.
[quote=vanzella]muito legal o topico, mas mesmo o mais basico como:
public void setDataNascimento( Timestamp data ) {
this.dataNascimento = data;
}
não seria inutil, não consigo ver outra forma de encapsular isso. Ja imaginou a zona que seria se os atributos fossem publicos, todo mundo metendo a mão. Bom sei lá, fala ai galera…[/quote]
Na verdade uso sem saber o real motivo tbm.
Uma padronização da sun, que nunca parei pra analisar.
[quote=esb][quote=vanzella]muito legal o topico, mas mesmo o mais basico como:
public void setDataNascimento( Timestamp data ) {
this.dataNascimento = data;
}
não seria inutil, não consigo ver outra forma de encapsular isso. Ja imaginou a zona que seria se os atributos fossem publicos, todo mundo metendo a mão. Bom sei lá, fala ai galera…[/quote]
E com o getDataNascimento() eu não meto a mão?[/quote]
Existem casos que fazem sentido o setter, mesmo sem validacao dentro. Porque a validacao pode vir a ser necessaria DEPOIS.
Mas o ruim de getters e setters é que muitas vezes eles sao criados sem necessidade alguma! Poderiamos dar mais logica ao objeto de uma série de maneiras.
agora comprendo perfeitamente que so se deve “abrir” o acesso aos atributos que realmente sao essencias à interface publica da classe. O que é de conhecimento apenas da propria classe, e que as demais classes nem devem saber que existe, fica eternamente privado, e ISSO SIM quer dizer encapsulamento.
agora, uma pergunta…
pq que RAIOS ferramentas como o eclipse, JDev, tem a tal da “Generate getters and setters”? Agora entendo perfeitamente que isso é um veneno, e devia ter seu nome trocado pra “Quebrar o encapsulamento da classe”.
Fora o fato de se fazer o setter sem pensar. Por exemplo:
[code]public class Semaforo {
enum Cor {VERMELHO, AMARELO, VERDE};
private Cor cor;
public void setCor(Cor cor) {
this.cor = cor;
}
public Cor getCor() {
return Cor;
}
}[/code]
Um set desses é claramente danoso. Um semáforo tem uma série de estados. Você não pode simplesmente passar do verde para o vermelho, sem ir para o amarelo. Nem tem qualquer sentido passar do vermelho para o amarelo. Poderíamos colocar essas regras usando exceptions, como descrito ali em cima, mas ainda teríamos problemas. O maior dele é que estaríamos delegando a implementação das trocas de estado para fora da classe, e não dentro, como deveria ser. Isso é uma violação do encapsulamento, não dos atributos, mas sim, da implementação.
O ideal então é eliminar o set e deixar apenas o método “proximaCor”, que faria a troca correta de estado.
Sem contexto essa frase não faz sentido (e provoca uns comentários de quem não leu o artigo mas quer opinar mesmo assim, como vimos em resposta ao seu post).
Dentro do artigo ela está colocara logo após uma demonstração de que é possível ter exatamente o mesmo ‘encapsulamento’ (que [b]não é encapsulament/b]) provido por get/set com uma struct C, por isso que o texto afirma que get/set é um atributo público mais lento.
[quote=pcalcado][quote=fabiocsi]
Entretanto, uma frase me deixou um pouco confuso. Ele pergunta o seguinte no artigo: “… (afinal, o que são get e set além de um jeito mais lento de fazer um atributo público?)…”
[/quote]
Sem contexto essa frase não faz sentido (e provoca uns comentários de quem não leu o artigo mas quer opinar mesmo assim, como vimos em resposta ao seu post).
Dentro do artigo ela está colocara logo após uma demonstração de que é possível ter exatamente o mesmo ‘encapsulamento’ (que [b]não é encapsulament/b]) provido por get/set com uma struct C, por isso que o texto afirma que get/set é um atributo público mais lento.[/quote]
sim…
Realmente só depois que o Paulo postou que eu consegui realmente enteder o siginficado dessa sua frase. btw excelente o artigo, me fez entender ‘finalmente’ o que é encapsulamento. Estou lendo mais da fragmental.
confesso que algumas das respotas foram um tanto meio que… rs… nada a ver
acho que estamos num Forum técnico, e os posts de muitas pessoas que ‘dizem o que querem’ me fizeram entender bastante coisas de OO. cuidado com esses comentarios
boa tarde fabiocsi,
Essa coisa de utilizar um padrão de projeto ou qualquer outra coisa sem saber a finalidade acontece com todo mundo, tenho certeza que todos já usaram alguma coisa sem saber o real motivo rsrs, mas o que difere o bom profissional é buscar saber o porque de estar usando, qual a finalidade.
Isso acontece muito, principalmente em Frameworks, muitos utilizam sem saber o que realmente acontece.
O uso de gets e sets é tão rotineiro que as vezes não fundamentamos o por que usar.
[quote=vanzella]boa tarde fabiocsi,
Essa coisa de utilizar um padrão de projeto ou qualquer outra coisa sem saber a finalidade acontece com todo mundo, tenho certeza que todos já usaram alguma coisa sem saber o real motivo rsrs, mas o que difere o bom profissional é buscar saber o porque de estar usando, qual a finalidade.
Isso acontece muito, principalmente em Frameworks, muitos utilizam sem saber o que realmente acontece.
O uso de gets e sets é tão rotineiro que as vezes não fundamentamos o por que usar.[/quote]
[quote=vanzella]muito legal o topico, mas mesmo o mais basico como:
public void setDataNascimento( Timestamp data ) {
this.dataNascimento = data;
}
não seria inutil, não consigo ver outra forma de encapsular isso. Ja imaginou a zona que seria se os atributos fossem publicos, todo mundo metendo a mão. Bom sei lá, fala ai galera…[/quote]
Os métodos GETS e SETS, a meu ver, vieram para prover 3 formas de encapsulamento:
1- Encapsula a manipulação de um objeto antes dele ser setado em outro objeto ou deixa um gancho para que esta manipulação seja feita posteriormente;
public void setDataNascimento( Timestamp data ) {
// faz algo em data
this.dataNascimento = data;
}
2- Encapsula a manipulação de um objeto antes dele ser recuperado de outro objeto ou deixa um gancho para que esta manipulação seja feita posteriormente;
public void getDataNascimento() {
// faz algo em data
return dataNascimento;
}
3- Encapsula o PROPRIO ATRIBUTO do objeto podendo ser adicionada manipulações. Em outras palavras aplica o conceito de composição!
public void setDataNascimento( Timestamp data ) {
// faz algo em data
this.dataNascimento = data.CLONE;
}
public void getDataNascimento() {
// faz algo em data
return dataNascimento.CLONE;
}
[]s
Está aberta a temporada de caça ao Shoes! O que essa galera viajante tem pego no seu pé heim rappa! Daqui a pouco vc esta igual ao Luca sendo apedrejado por paradas que não tem nada a vê!
Se esta classe te retorna cópias de seus atributos e faz cópia dos parametros dos métodos Sets. Isso te impede que vc altere os atributos sem passar pelos métodos da classe. Isso lhe mostra que vc ainda sim tem encapsulamento e esta mantendo sua composição.
A chave disso tudo é a cópia! Se vc alterar fora do objeto de origem só vai esta alterando a cópia e não o objeto de onde vc o extraiu!
Derrepente nos dois artigos eles não quiseram se aprofundar…
