Singleton vererben

[Krabat]

Ist es möglich eine (am besten abstrakte) Klasse zu haben, die die Methodik des Singletons implementiert, so daß die erbenden Klassen auch sofort Singletons sind? Zudem sollten noch einige Methoden vorgegeben sein, weche die bereits implementiert sind und solche, die unbedingt implmentiert werden müssen (daher abstract).

Falls das zu allgemein ist, formuliere ich das Problem anhand meines Beispiels nochmal richtig aus.

 

[Gast]

eine klasse, die als singleton funktionieren soll, muss doch eine methode zur verfügung stellen, die eine instanz dieser klasse liefert (fall bisher noch keine existiert). da abstrake klassen aber nur den methodenrumpf beinhalten und nicht die implementierung der methode, dürfte das bei abstrakten klassen meiner meinung nach nicht funktionieren. ich hoffe, ich erzähle jetzt nix falsches...

 

[Guest]

So ungefähr

abstract class AbstractSingleton {
  private static AbstractSingleton instance = null;

  protected AbstractSingleton() {
  }

  public final static synchronized AbstractSingleton getInstance() {
    if(instance == null)
      instance = createInstance();
    return instance;
  }

  protected static AbstractSingleton createInstance();
  public void sayYo();

}

class Singleton extends AbstractSingleton {

  protected Singleton() {
    super();
  }

  protected static AbstractSingleton createInstance() {
    return new Singleton();
  }

  public void sayYo() {
    ...
  }
}

 

[Gast]

ich meinte natürlich nicht den rumpf der methode, sondern die deklaration der methode. dein getInstance darf in einer abstrakten klasse so nicht existieren, implemnetiert wird die methode erst in einer abgeleiteten klasse

 

[Guest]

Hää? ???:L

 

[bygones]

So ungefähr

abstract class AbstractSingleton {
  private static AbstractSingleton instance = null;

  protected AbstractSingleton() {
  }

  public final static synchronized AbstractSingleton getInstance() {
    if(instance == null)
      instance = createInstance();
    return instance;
  }

  protected static AbstractSingleton createInstance();
  public void sayYo();

}

class Singleton extends AbstractSingleton {

  protected Singleton() {
    super();
  }

  protected static AbstractSingleton createInstance() {
    return new Singleton();
  }

  public void sayYo() {
    ...
  }
}

nur mal so als kleiner Tipp: kompilier das mal.....

deine createInstance Methode ist nicht möglich... sie muss in dieser Form abstract definiert werden. dann kann sie nicht static sein - folglich musst du eine dummy Impl. nehmen die dir null zurückliefert.

ich versteh nicht worin der sinn liegt ein Singleton zu vererben.... nur um die getInstance methode zu sparen ?... mhm naja

 

[Guest]

nur mal so als kleiner Tipp: kompilier das mal.....

OK, static abstract ist abgekackt.
Ich habe es hier nur so auf die Schnelle zusammengetippt, ohne viel zu überlegen.

Oh Herr, lass' Hirn regnen. :autsch:

 

[KSG9|sebastian]

abstract class SingleAbs{
   protected SingleAbs(){}
   private static SingleAbs instance = null;

   public static void getInstance(String clazz){
      try{
         instance = (SingleAbs)Class.forName(clazz).newInstance();
         return instance;
      } catch(ClassCastException){
         return null;
      }
   }
}

Wenn ich jetzt von der Klasse erbe

class Erbe extends SingleAbS{
// blah Code
}

Dann hindert mich die Vererbung noch lange nicht dran, der Klasse Erbe nen public-Konstruktor zu verpassen und somit das Singleton wieder zu verwerfen.

 

[Sky]

Ist es möglich eine (am besten abstrakte) Klasse zu haben, die die Methodik des Singletons implementiert, so daß die erbenden Klassen auch sofort Singletons sind? Zudem sollten noch einige Methoden vorgegeben sein, weche die bereits implementiert sind und solche, die unbedingt implmentiert werden müssen (daher abstract).

Falls das zu allgemein ist, formuliere ich das Problem anhand meines Beispiels nochmal richtig aus.

Wofür braucht man denn sowas ? Vielleicht hilft Dir ja auch ein anderes Pattern...

 

[Krabat]

ich versteh nicht worin der sinn liegt ein Singleton zu vererben.... nur um die getInstance methode zu sparen ?... mhm naja

Nicht nur, es soll eine Art Vorgabe sein, die besagt, daß erbende Klassen von der abstract class jeweils Singletons sein sollen und einige Methoden noch selbst implementieren müssen.

 

[Sky]

Aber warum müssen es unbedingt Singletons sein ?

Evtl. würde es Sinn machen, das FactoyPattern anzuwenden. Die Factory gibt Dir immer die richtige Instanz zurück und mittels Interfaces oder abstracter Basisklasse kannste deine gewünschten Methoden bekommen...

 

[Krabat]

Wofür braucht man denn sowas ? Vielleicht hilft Dir ja auch ein anderes Pattern...

Also ich bastel gerade eine logging lib, deren Haupttyp LogCore von Observable erbt. Diesem sollen Oberserver übergeben werden, die die Output Möglichkeiten wie Ausgabe in der Console, in eine TextDatei, grafische Ausgabe realisieren können. Zum einen braucht man zB. nur eine Ausgabe-Klasse Console (bei Text/grafisch könnte es unter Umständen anders aussehen), zum anderern kann man nicht auf die eingefügten Observer beim Observable zugreifen, was es schwierig macht, diese wieder zu entfernen.
Daher habe ich angenommen, daß man am einfachsten alle Outputs als Singletons vererbt und so einfach auf deren einzige Instanz zugreifen kann, diese also nicht mehr seperat in einer eigenen Struktur speichern muss.
Könnte es anders einfacher/sinnvoller gehen?

 

[bygones]

Könnte es anders einfacher/sinnvoller gehen?

wie Sky erwähnt - Factory Pattern

andere Möglichkeit - änhlich Factory - eine Singleton Klasse (z.b. Config Klasse), die initialisiert einmal den gewünschten Logger.... wenn er gebraucht wird holt man sich ihn über die Config

 

[Krabat]

andere Möglichkeit - änhlich Factory - eine Singleton Klasse (z.b. Config Klasse), die initialisiert einmal den gewünschten Logger.... wenn er gebraucht wird holt man sich ihn über die Config

Meine Haupt Log-Klasse ist auch schon ein Singleton (offenbar mag ich die mehr als OO ), welches beim ersten Aufruf initialisiert wird und seine Einstellungen über ein Properties file lädt. Danach sind noch Veränderungen wie add/remove Output etc. möglich, können aber auch über die Einstellungen im Properties File geregelt werden. Wo wäre der Vorteil von einer Config Klasse gegenüber meinem SingleLog?

 

[bygones]

man sollte Singletons so wenig wie möglich einsetzen....

ich persönliche habe lieber eine ManagerKlasse, die intern regelt (mit Information die sie wo auch immer her), wie was gemacht wird. Z.b. loggen....

U.a. Vorteil: ein singleton, keine Probleme von irgendwelchen Vererbungshierarchien. Intuitiv würde ich eher zu einem Interface als Basisklasse tendieren für die Logger....

 

[Krabat]

ich persönliche habe lieber eine ManagerKlasse, die intern regelt (mit Information die sie wo auch immer her), wie was gemacht wird. Z.b. loggen....

Habe lange darüber nachgedacht und empfinde es ebenfalls als beste Lösung. Am Log Singleton gefiel mir, daß man von jeder Klasse/Methode aus überall Log.getInstance().info("kleine Info hier"); schreiben konnte, ohne die Log Instanz jeweils durch die Klassen "durchreichen" zu müssen, aber mittels Deiner ManagerKlasse kann das fast genauso komfortable gelößt werden (Log log = ManagerKlasse.getLogInstance(); log.info("kleine Info hier");) und man kann alle möglichen Singletons darüber verwalten, bzw. bei multithreading mehrere Log Instanzen bilden, um nicht in Verlegenheit zu kommen, in einen deadlock zu laufen. Danke.