Como tornar uma "propriedade" efetivamente ReadOnly?

Programação Arquitetura
#1

Ola,

Sei que isso eh basico, mas como estou comecando com Java agora nao consegui ainda chegar a resposta:

Imagine que eu tenha uma classe Person (Usei classes Deprecated, pois eh so um simples exemplo):

package testgetters;

import java.util.Date;

/**
 *
 * @author Pen_Fold
 */
public class Person {

    //<editor-fold defaultstate="collapsed" desc="Fields">  
    
    private String strName;
    private Date objDOB;
    
    //</editor-fold> 
    
    //<editor-fold defaultstate="collapsed" desc="Constructors">  
    
    public Person() {
        
        objDOB = new Date(2005, 06, 06);
    }
    
    //</editor-fold>    

    //<editor-fold defaultstate="collapsed" desc="Properties">  
    
    public String getName() {
        return strName;
    }

    public Date getDOB() {
        return objDOB;
    }
    
     //</editor-fold>
    
}

Dai tenho o teste a seguir (nao reparem na pessima codificao, era somente um teste):

[code]package testgetters;

/**
*

  • @author Pen_Fold
    */
    public class Main {

    /**

    • @param args the command line arguments
      */
      public static void main(String[] args) {
      // TODO code application logic here

      Person objPerson = new Person();

      System.out.println("Year: " + objPerson.getDOB().getYear() );

      objPerson.getDOB().setYear(2008); // This shouldn’t be possible. How to avoid that?

      System.out.println("Year: " + objPerson.getDOB().getYear() );

    }

}
[/code]

Qual o melhor enfoque para evitar que uma propriedade READ_ONLY seja alterada assim tao simplesmente, e com isso quebrar o encapsulamento?

Clonar o objeto seria algo viavel? Penso em caso onde existam muitos objetos aninhados, e isso poderia afetar negativamente a performance.

Tenho certeza que exista uma solucao amplamente utilizada para isso, mas infelizmente nao sei qual eh.

Obrigado

#2

Oi pen

Excelente pergunta.

Quando é referencia para um objeto ou para uma array, precisamos mesmo fazer uma copia defensiva. É a sugestao do Effective Java. Realmente tem esse problema que voce falou, em as vezes isso causar um deep cloning “deep demais”. Mas normalmente se estamos trabalhando com uma API mais voltada a imutabilidade (como o Joda Time), os objetos pelos quais nos somos compostos ja sao imutaveis, entao ai nao precisa fazer deep cloning.

abracos

#3

Ou então:

public class Person { .... public int getYOB() { return objDOB.getYear(); } }

#4

[quote=cmoscoso]Ou então:

public class Person { .... public int getYOB() { return objDOB.getYear(); } } [/quote]

Otimo! Acho que o melhor é fazer uma mistura das duas abordagens.

#5

O seu exemplo me pareceu totalmente imutável, ou seja, suas propriedades são efetivamente read-only.

String e Date são imutáveis, logo os seus getters estão seguros.

Ruby tem um método interessante que é o freeze que te permite transformar um objecto mutável em imutável. Java não tem isso, logo o que se tem são objetos diferentes, um mutável e outro imutável. Ex: String e StringBuilder; Date e Calendar, etc.

Java tem até uma história interessante que é o fato de nas primeiras versões por erro mesmo o java.util.Date era mutável !!! Corrigiram isso rapidamente nas versões posteriores mas o cara que fez isso deve ter tomada uma bela chamada. :slight_smile:

#6

Sérgio, objetos Date não são imutáveis.

#7

Obrigado a todos pelas respostas.

Sergio, se voce executar o exemplo vera que a saida eh 2005 e depois 2008.

Mas usei Date so como exemplo, para tentar, de maneira simples, ilustrar o problema.

Pelo jeito nao existe algo simples para garantir o encapsulamento para objetos e arrays (como o Paulo comentou).

Seria legal se existisse uma qualificador readOnly ou algo assim para o valor de retorno/ou variavel de classe (nao apenas para a referencia do objeto), mas tenho certeza que isso nao seria facil (ou talvez nem viavel) de ser implementado pela JVM, senao ja estaria disponivel.

Mais uma vez, obrigado pelas respostas!
Abraco

#8

Qual o problema da solução abaixo?

package testgetters;

import java.util.Date;

    public Date getDOB() {
        return new Date(objDOB.getTime());
    }
    
     public void setDOB(Date dob){
        this.objDOB = new Date(dob.getTime());
    }
}
#9

Ola Ivan,

Entao, isso funciona sim para objetos nao aninhados (Corrija-me se estiver enganado).
Mas o problema permaneceria em casos de objetos que tivessem outros objetos aninhados. Para ser realmente efetivo, teriamos que “reinstanciar” um novo objeto (nos getters) para cada propriedade publica dos objetos aninhados (menos para tipos primitivos).
Eu acho que isso impactaria negativamente na performance, nao? E, na minha opiniao, tambem nao seria uma solucao elegante (as vezes temos que contar com solucoes nao elegantes…rs).

O Sergio apontou o [color=red]freeze do Ruby[/color] e apesar de apenas ter dado uma rapida olhada, pareceu ser o que eu gostaria de encontrar no Java, para, de forma simples e descritiva, protejer o encapsulamento.

Outro problema que poderia acontecer no meu exemplo inicial eh que um usuario desse objeto poderia alterar o valor de DOB atraves do Getter e todas as constraints do Setter (caso existissem) seriam ignoradas (bye bye encapsulamento).

Muito obrigado por compartilhar sua opiniao.
Abracos

#10

Sérgio, objetos Date não são imutáveis.[/quote]

Falando sério!? Sempre achei que fosse. Calendar eh mutavel e date imutavel. Entao Java nao tem um date imutavel???

Follow-up:

Realmente estive equivocado durante muito tempo:

Então vc tem que criar o seu proprio objeto date nao-padrao imutavel. Nada legal…

Entao faz o seguinte, guarda suas datas como um long e se quiser retornar como date cria um novo a cada vez que chamarem o getter.

#11

Mau meu! acho que nao deixei claro.

Eh o seguinte, usei DATE como [color=red]um exemplo apenas[/color], poderia ser qualquer outro objeto (ate mesmo um criado pela propria equipe), por exemplo Address (que teria GetStreetName()) poderia estar estar agregado a classe pessoa, ao inves do DATE. Teriamos o mesmo problema.

Sergio, sua dica do freeze foi legal, achei muito pratica e elegante. Espero que tenhamos isso no Java um dia (Nao sei o que isso vai ocasionar de mudancas na JVM).

Um abraco a todos e obrigado

#12