Pelo que eu entendi, a quest�o � que o objeto "casa" criado dentro do metodo
criaNovaCasaAlugada() n�o deveria alterar o atributo alugada, atributo esse
que a principio � do seu "criador" (o objeto this).
Mas ele n�o alterou o atributo do objeto this, mas o atributo alugada da sua
pr�pria instancia, ou seja this.alugada est� preservada.
Acho que o "problema" � mais de sintaxe da linguagem do que de conceito de
OO: o compilador achou um atributo alugada dentro da classe Casa, e validou
o codigo.
Do ponto de vista de codifica��o isto est� correto: um atributo privado est�
sendo manipulado dentro da pr�pria classe.
Testem o codigo abaixo para ver o resultado.
Roberto Tatemoto
PS: Mas que isto fica esquisito...
class Casa implements Cloneable
{
private boolean alugada;
public Casa()
{
}
public Casa criaNovaCasaAlugada() throws Exception
{
Casa casa = (Casa)this.clone();
casa.alugada = true;
System.out.println("Atributo do objeto this " + this.alugada );
return casa;
}
public void setAlugada(boolean alugada)
{
this.alugada = alugada;
}
public boolean isAlugada()
{
return alugada;
}
}
public class MainCasa
{ public static void main(String[] args) throws Exception
{
Casa casa = new Casa();
casa.setAlugada(false);
Casa oClone = casa.criaNovaCasaAlugada();
System.out.println("Original " + casa.isAlugada());
System.out.println("Clone " + oClone.isAlugada());
}
}
> Se for para ser meio "xiita", de fato o jconde tem raz�o. A casa this � um
objeto e a
> casa nova � outro, logo um n�o deveria mexer nos atributos do outro. Mas
como eles
> pertencem a mesma classe, acaba sendo poss�vel esse tipo de c�digo.
Teoricamente, � um
> furo, mas na pr�tica, o programador da classe � o cara mais indicado para
"fu�ar" na
> classe � vontade, pois ele (em princ�pio) sabe exatamente o que deve ou
n�o fazer com
> cada atributo nessa classe, assim o risco de fazer uma besteira muito
grande �
> pequeno.
>
> 15/11/02 10:27:56, "Herbert Alexander Faleiros" <[EMAIL PROTECTED]>
wrote:
>
> >Se n�o me engano (corrijam-me se estiver errado) todos os m�todos
> >"public" desta sua classe podem acessar ou modificar as vari�veis de
> >inst�ncia "private" desta mesma classe. N�o tem nada errado nisto, �
> >assim que funciona mesmo, mas isto se aplica somente aos m�todos
> >"public" da classe, se vc tentar alterar ou acessar diretamente a
> >vari�vel, sem ser atrav�s de um destes m�todos vc receber� algo do tipo:
> >"variable alugada has private acess in class Casa"... Ou seja, apenas os
> >m�todos "public" da classe podem e devem acessar/modificar vari�veis de
> >inst�ncia "private" na classe.
> >
> >Herbert Alexander Faleiros
> >Administrador de redes NT/W2K
> >Programador Java / Webmaster
> >Graduando em F�sica - UFSCar
> >[EMAIL PROTECTED]
> >[EMAIL PROTECTED]
> >(16) 9117-2962
> >
> >
> >-----Mensagem original-----
> >De: Jos� Augusto Cerqueira Cond� [mailto:[EMAIL PROTECTED]]
> >Enviada em: sexta-feira, 8 de novembro de 2002 17:46
> >Para: '[EMAIL PROTECTED]'
> >Assunto: [java-list] Restri��o de acesso em classes x objetos
> >
> >Colegas,
> >
> >Recentemente me atentei a uma quest�o interessante. Os n�veis de
> >restri��o
> >de acesso a atributos e m�todos de uma classe, implementados pela
> >linguagem
> >java, se aplicam apenas a classes e n�o a objetos.
> >
> >Tomem como exemplo a classe abaixo :
> >
> >
> >public Casa
> >{
> >
> > private boolean alugada;
> >
> > public casa()
> > {
> > }
> >
> >
> > public Casa criaNovaCasaAlugada()
> > {
> > Casa casa = (Casa)this.clone();
> > casa.alugada = true;
> > }
> >
> > public void setAlugada(boolean alugada)
> > {
> > this.alugada = alugada;
> > }
> >
> > public boolean isAlugada()
> > {
> > return alugada;
> > }
> >
> >}
> >
> >Apesar de parecer estranho o atributo "alugada" estar sendo acessado
> >externamente, o m�todo "criaNovaCasaAlugada" est� correto do ponto de
> >vista
> >da linguagem java. Mas em rela��o �s boas maneiras da Orienta��o
> >Objetos,
> >isto n�o seria aberra��o (objetos acessando atributos protegidos de
> >outros
> >objetos)?
> >
> >Atenciosamente,
> >
> >JConde
> >[EMAIL PROTECTED]
> >
> >------------------------------ LISTA SOUJAVA
> >----------------------------
> >http://www.soujava.org.br - Sociedade de Usu�rios Java da Sucesu-SP
> >d�vidas mais comuns: http://www.soujava.org.br/faq.htm
> >regras da lista: http://www.soujava.org.br/regras.htm
> >historico: http://www.mail-archive.com/java-list%40soujava.org.br
> >para sair da lista: envie email para
> >[EMAIL PROTECTED]
> >------------------------------------------------------------------------
> >-
> >
> >
> >
> >------------------------------ LISTA SOUJAVA ----------------------------
> >http://www.soujava.org.br - Sociedade de Usu�rios Java da Sucesu-SP
> >d�vidas mais comuns: http://www.soujava.org.br/faq.htm
> >regras da lista: http://www.soujava.org.br/regras.htm
> >historico: http://www.mail-archive.com/java-list%40soujava.org.br
> >para sair da lista: envie email para [EMAIL PROTECTED]
> >-------------------------------------------------------------------------
> >
> +++++++++++++++++++++++++++++++++++
> Ana Paula Brand�o Lopes, M. Sc.
> Universidade Estadual de Santa Cruz
> Ilh�us-BA
> 73-680-5271
> +++++++++++++++++++++++++++++++++++
>
>
>
> ------------------------------ LISTA SOUJAVA ----------------------------
> http://www.soujava.org.br - Sociedade de Usu�rios Java da Sucesu-SP
> d�vidas mais comuns: http://www.soujava.org.br/faq.htm
> regras da lista: http://www.soujava.org.br/regras.htm
> historico: http://www.mail-archive.com/java-list%40soujava.org.br
> para sair da lista: envie email para [EMAIL PROTECTED]
> -------------------------------------------------------------------------
------------------------------ LISTA SOUJAVA ----------------------------
http://www.soujava.org.br - Sociedade de Usu�rios Java da Sucesu-SP
d�vidas mais comuns: http://www.soujava.org.br/faq.htm
regras da lista: http://www.soujava.org.br/regras.htm
historico: http://www.mail-archive.com/java-list%40soujava.org.br
para sair da lista: envie email para [EMAIL PROTECTED]
-------------------------------------------------------------------------
