Única instância. Como resolver?

controla atravez do contrutor…

class pai
{
   static HashSet h = new HashSet();
   protected pai()
   {
      if(h.contains(this.getClass()))
          throw new Error("instanciando mais de 1 vez essa classe!");
      h.add(this.getClass();
   }
}

Se fosse C++, 1 template ja resolveria esse problema…

Hmmmm… boa idéia, louds!

Mesmo assim, as subclasses vão ter que implementar um getInstance() da vida. E chamar o super() no construtor, ou vai explodir tudo

[]'s
-cv

É… acho que não vai dar pra escapar de alguma codificação maçante e inútil, né?!

Talvez até dê… pegue o Together Control Center, carregue todas as classes num diagrama de classes, selecione as que interessam e dê um belo “Apply Pattern/Singleton” nelas

Ainda assim vai gerar código em cada classe - na verdade era isso que eu queria evitar.

Mas fazer o que… paciência.

Obrigado pela ajuda de vcs.

você pode utilizar um Factory para isto,
e factory cuida disto para você
construtor package level para as classes e acho que resolve o problema.

como o Urabatan falou, um factory. melhor ainda, um factory de Singletons na classe Pai. O clasico Multiton

class Pai {

  // esse aqui as subclasses podem popular no static initializer
  protected static Map hashDeSubClasses = new Hashtable();

  // esse aqui vai ser populado pelo getInstance a seguir
  protected static Map hashDeInstanciasDeSubClasses = new Hashtable();

  protected Pai() {}

  public static Pai getInstance(String tipo) { // poderia ser um int de uma enum
    // tira do hash o tipo, algo como
   Pai instance = (Pai) hashDeInstanciasDeSubClasse.get(tipo);
   if (pai == null) {
     // nao foi inicializado ainda uma isntancia desse tipo
     Class class = hashDeSubClasses.get(tipo);
     instance = (Pai) class.newInstance(); // supondo construtor default
     hashDeInstanciasDeSubClasse.put(tipo, instance);
   }
   return instance;
}

Acoplamento um pouco grotesto, classes filhas precisam conhecer a implementacao da pai, mas… Tambem falta ai sincronizacao e as excecoes lancadas pelo newInstance(). Uma das filhas ficaria ± assim:

class Filha1 extends Pai {

  // da um "toque" pro pai, de que eu existo!!!
  static {
    hashDeSubClasses.put("esteTipoDeSingleton", Filha1.class);
  }

  //.. overrides
}

Que falta faz um SL275…

Ensinamos nos cursos oficiais da SUN a todos os JavaBabies como usar e implementar um SingleTon nos cursos SL275, SL314 e SL500…

Gente… Façam treinamento tbm… O retorno é garantido… Heheheh

Ah, Oziel, me poupe. O problema aqui não é saber ou não fazer um singleton, o problema aqui é gerenciar uma cacetada de singletons, coisa que com certeza nenhum curso da Sun ensina :x

Oziel, realmente aqui nao eh singleton nao. Eh um factory/multiton no melhor estilo DriverManager/Connection do java.sql, ja que a filha precisa se registrar a pai (ou a composta precisa se registrar na agregadora, tanto faz), para que a pai saiba q a filha existe.

Muito diferente do singleton. com singleton mesmo, voce nem sublcasse pode ter porque seu construtor deveria ser private. O louds tambem colocou o construtor protected ai nao a toa.

Relmente o problema não se trata de um simples Singleton. E eu já havia citado isso desde o primeiro post…

O cara não perde uma chance de vender o peixe dele. :shock:

Bem, desse factory/multiton eu gostei…

Blz pessoal!!! Muito obrigado!!!

Não pude deixar de perceber que alguns amigos nossos no fórum, em vez de ajudar, como em muitos casos ajudaram, apenas encaminharam uma sugestão de curso. Por que não detalhar aqui no forum como fazer tal tarefa. Fica aqui a minha indiguinação, apesar de ser iniante, acredito que o proposito deste e qualquer fórum seja a ajuda mútua e não a promoção de alguém ou algo em especial.