Verificar a existência de um objeto na memória

Por que, entao, nao é o caso?

pode ser assim?

class X {
   public static int COUNT ;

   public X() { COUNT++; }

   protected void finalize() {  COUNT--; }
}

e no codigo:

....
....
X x = null;
if ( X.COUNT == 0 ) x = new X();

Ei VMM? Qué isso?

Porque eu não quero ter que controlar classe por classe, mas sim, construir um repositório de instâncias.

Fui!

Ainda não resolve meu problema, pois se fosse esse o caso, eu usaria o pattern Singleton [GoF]. Mas… valeu o interesse em ajudar!

Mas vc vai ter que fazer alguma coisa relacionada ao que o colega mostrou… pode nao ser igual, mas algo no estilo:

Class MinhaClasse {
    private static boolean hasInstance = false;

    public MinhaClasse() {
        MinhaClasse.hasInstance= true;
    }

    public static boolean instanceExists() {
        return (MinhaClasse.hasInstance == true);
    }
}

....
if (MinhaClasse.instanceExists() == false) {
    MinhaClasse m = new MinhaClasse();
}
...

Rafael

Use o pattern de Singleton Factory, o Paulo postou sobre ele em um tópico semelhante a um tempo atras.

Procure no forum por essa pattern.

Caso contrario vc pode implementar isso usando AOP, né cv?
Não teria como criar um point-cut, esse é o termo?, que interceptaria todas chamadas de new para as várias classes em questão e só instanciaria um objeto no caso de já não existir um registrado…

Nossa, mas usar AOP nesse caso eh jogar uma Scania em cima de uma pulga.

Parece que ele ta querendo uma maneira “automatica” de fazer isso, sem modificar a classe… Mas eh meio insano, muito trabalho para pouco caso. Simplesmente implementar um verificador ( que seja uma forma de singleton ou qualquer outro creational relacionado ) resolve o problema… eh tudo questao de boa vontade

Rafael

“louds”:

Caso contrario vc pode implementar isso usando AOP, né cv?
Não teria como criar um point-cut, esse é o termo?, que interceptaria todas chamadas de new para as várias classes em questão e só instanciaria um objeto no caso de já não existir um registrado…

Usar pointcuts pra retornar um objeto do pool ao inves de instanciar um novo e’ uma coisa meio voodoo demais pro meu gosto, mas sim, eh perfeitamente possivel com AOP. Mas um bom factory te faz o mesmo aqui… entao nao tem mta utilidade usar AOP quando vc pode simplesmente tornar o construtor protected e colocar uma factory em cima, que faz o que bem entender com as instancias

Sobre advices em construtores, o AspectWerkz ainda nao os implementa por alguns probleminhas tecnicos… devem entrar na versao 0.10, prevista pra daqui mais ou menos um mes, mas, se vc estiver muito na seca pra brincar com isso, de uma olhada no AspectJ

Aêêê javamans, valeu!!!

Conheço os patterns Factory e Singleton [GoF], mas o que eu realmente queria fazer, é garantir que não seria possível instânciar uma classe uma classe que já tivesse uma instância.

Por que? Porque algum programador malvado poderia se recusar a usar o factory e usar um “new” diretamente.

Tá, isso poderia ser garantido com o Singleton, né? Sim, mas eu não queria colocar código pra “singleton” em todas as class, mas sim, ter um controlador centralizado.

Acho que é utopia o que estou querendo, só achei que fosse possível de fazer! (mas talvez até seja :D)

Para não permitir que a pessoa utilize o new é só colocar o construtor privado (que é um dos itens da implementação de um singleton).
Realmente querer que a pessoa dê new e não crie um objeto novo creio que não seja possível, pois aí você vai ter que escrever um construtor para a classe e a primeira coisa que um construtor comum faz é chamar o construtor da superclasse (poderia ser outro construtor da mesma classe, mas não é o comportamento padrão, então nem adianta analisar a possiblidade) e não teria como você alterar toda a hierarquia até object para fazer o contrutor não criar um objeto novo.

Ah, sim, com certeza, construtor privado é obrigatório na implementação de um singleton. Mas, como já disse anteriormente, não é o caso.

O que eu gostaria, é de acessar a memória e saber se já existe instância de uma determinada classe. Se eu pudesse fazer isso, conseguiria implementar um “controlador global de instâncias”, onde eu faria algo + ou - assim:

Classe objeto;

...

objeto = ControladorGlobalDeInstancias.getNovaInstancia(Classe.class);

...

Manjô?

Mas beleza… vou construir um controlador desses (possívelmente um Factory) usando uma HashMap mesmo, ao invés de acessar a memória .

Se alguém der um “new”, dou umas porradas nele!

Falow!

Se AOP é chutar demais o balde usa xdocket então…

crie uma tag @singleton que então gera o código necessario pra tornar tua classe um singleton…

“le-silva”:

Mas beleza… vou construir um controlador desses (possívelmente um Factory) usando uma HashMap mesmo, ao invés de acessar a memória .

Se alguém der um “new”, dou umas porradas nele!

Eu diria que resolver na porrada nao eh uma solucao mto amigavel, mas que pode funcionar se alguem conseguir passar por cima de um construtor private ou protected, por exemplo, enfiando um objeto no pacote errado só pra conseguir fazer isso

No mais, Factory, Factory, Factory.

O que é esse tal AOP? :?:

Tente usar isto:

public class Repository  {

    private static Repository instance;

    public static Repository getInstance() {
        if (instance == null)
            instance = new Repository();
        return instance;
    }


    public Repository() {
		// faz o que tem que fazer.....
    }
}

e quando for instanciar um “novo” Repository:

Repository reposit = Repository.getInstance();

Assim você não precisa se preocupar em verificar se já existe uma instância do objeto cada vez que desejar cirar uma “nova” instancia.

Espero que ajude.

Ah, o pattern Singleton [GoF]? Conheço!

Mas acho que você não sacou a minha idéia de ter uma “repositório de objetos”…

Eu não quero controlar as instâncias do gerenciador de repositório, pois isso eu certamente faria implementando singleton. O que eu quero realmente, é criar um “repositório para objetos diversos”, porém, sem me preocupar com a “storage” dos mesmos em tabelas de hash, e sim, acessando diretamente a memória para verificar a existência dos devidos objetos. Assim, não haveria como criar um objeto que ficasse “em oculto” ao gerenciador.

Falow!

Leandro,

Essa parte eu entendi, mas até agora vc nao explicou direito pra quê vc quer uma coisa dessas. Acho que a única coisa no Java que pode acessar a memoria diretamente assim é o garbage collector… e aposto que vc não está tentando desenvolver um… entao, qual o problema que vc está tentando resolver, aqui?

CV,

Sei que você já entendeu o que eu quero fazer! Mas só repeti o que já tinha explicado, porque um brother respondeu algo que já tinha sido discutido anteriormente. Forum tem dessas coisas: às vezes alguém que não está participando desde o inicio da discução, acaba respondendo ou perguntando algo que já rolou. É normal! (valeu Maurício!)

Quanto à sua pergunta…

É uma loucura que eu e uns brothers aqui do trampo estavamos pensando!

Se nós conseguissemos criar esse mecanismo, nós poderiamos controlar o número de instâncias de todas as classes do nosso sistema, em especial, nossos beans e classes de negócio, sem ter que, efetivamente, colocar código de controle de instâncias nessas classes.

Parece loucura, mas um bom framework que trabalhasse em todas as camadas do nosso sistema, deveria fazer isso! Não seria ótimo?

Hmm… se vc pensar bem, e’ isso que EJB e outros containeres fazem na area de gerenciamento de ciclo de vida… a diferenca e’ que no caso dos EJBs, por exemplo, nao da pra simplesmente mandar um new num session bean, se vc quiser aproveitar os recursos do container… por isso a coisa toda e’ feita atraves de factories… mas eu entendi a sua ideia, sim… vc quer se livrar, na verdade, nao dos singletons, mas sim das factories, certo?

Yeah!!! Pode crer!!!

Você sabe, né? Sempre tem aqueles que “dão um new” ao invés de utilizar uma “factory”. :roll:

Aaaaaaah bom, entao ta’

Ficam aqui entao as duas sugestoes que pipocaram no meio da discussao, entao:

• Fazer construtores protected: assim, so quem esta no mesmo pacote ou herda o objeto pode construi-lo

• Usar uma implementacao de AOP que suporte advices no construtor, pra puxar o objeto da factory ao inves de criar um novo. Nem sei se existe alguma (provavelmente o AspectJ suporta esse tipo de coisa, mas eu nao tenho certeza), e talvez nao compense o esforco…

Sobre AOP, de uma procurada aqui no GUJ, eu ja postei um monte de coisa ja faz um tempinho… e, sobre o AspectJ, http://aspectj.org

Vou procurar sim… fiquei curioso… :?: :?: :?:

Vc pode fazer uma factory “universal” se vc restringir os contrutores dos seus objetos especiais. Muitos containers te obrigam a ter um construtor sem argumentos, o pico se nao me engano te obriga a ter so um (por subclasse, i.e., uma subclasse pode ter um construtor diferente da classe pai).

Desse jeito, eles conseguem instanciar seu construtor por reflexao:

public Constructible newInstance(Class cl) {
   Object obj = loadedInstances.get(cl);
   if (obj == null) {
      obj = cl.getDeclaredConstructor(null).newInstance(null);
   }
   return (Constructible) obj;
}

Aquelao!!

Bom vc ter lembrado do Pico aqui… parece que eh um bom candidato a factory generica nesse caso… primeiro pq ja vem pronto, e segundo, pq é muito facil de usar

Para saber mais: http://picocontainer.codehaus.org

Voce pode utilizar aspect oriented programming e botar um hook antes do new.

Ou entao pode ser mais radical e mandar um runtime no contstrutor:

public class Foo { private boolean marcadorDeExistenciaTabajara = false; public Foo() { if ( marcadorDeExistenciaTabajara ) { throw new RuntimeException("Porrada mano!"); } marcadorDeExistenciaTabajara = false; } }