Singleton-Muster Java ->Nur eine Instanz einer Klasse erzeugen können

frager2345

frager2345

Aktives Mitglied
Hi, ich möchte , dass man von meiner Klasse nur eine instanz erzeugen kann. Dafür hab ich den Konstruktor auf privat geändert. Nun habe ich noch eine Methode geschrieben um den Konstruktor aufzurufen.
Java: 
private static Bibliothek unique = null;
Konstruktoren:
Java: 
private Bibliothek() {
    }

   private Bibliothek(ArrayList<Buch> buecher) {
        this.buecher = buecher;
   }

Methoden:
Code: 
public static Bibliothek instance() {
        if(unique == null){
            unique = new Bibliothek();
        }
        return unique;
    }

Jetzt ist bei mir hier die Frage wie ich es handhabe mit dem Konstruktor der ein Argument erwartet?
Hoffe es findet sich Hilfe 🙂
 
Zuletzt bearbeitet:
mach halt einen private setter für dein objekt und deine instance methode erwartet einen wert für den setter der dann instance aufruft, und zusätzlich hast du noch die alte instance methode die keinen parameter erwartet falls du singleton mit dem alten wert aufrufen willst aber dann ist man glaub ich bei spaghetti code ...
 
yfons123 hat gesagt.:
mach halt einen private setter für dein objekt und deine instance methode erwartet einen wert für den setter der dann instance aufruft, und zusätzlich hast du noch die alte instance methode die keinen parameter erwartet falls du singleton mit dem alten wert aufrufen willst aber dann ist man glaub ich bei spaghetti code ...
Zum Vergrößern anklicken....
Ah ok, ja das wäre eine Option. Dann hätte ich ja auch zwei instance methoden oder?
 
yfons123 hat gesagt.:
mach halt einen private setter für dein objekt und deine instance methode erwartet einen wert für den setter der dann instance aufruft, und zusätzlich hast du noch die alte instance methode die keinen parameter erwartet falls du singleton mit dem alten wert aufrufen willst aber dann ist man glaub ich bei spaghetti code ...
Zum Vergrößern anklicken....
Dein Geschreibe ist echt schwer zu verstehen. Funktioniert deine Umschalttaste nicht?

Statte deine instance() Methode einfach mit einem Parameter aus, den du an den Konstruktor weiterreichst. Problem ist nur, dass der Parameter nur einmal wirksam übergeben werden könnte, also nicht so schön.
 
das wäre ein Grundgerüst
Java: 
public class ClassSingleton {

    private static ClassSingleton INSTANCE;
   
   
    private ClassSingleton() {      
    }
   
    public static ClassSingleton getInstance() {
        if(INSTANCE == null) {
            INSTANCE = new ClassSingleton();
        }
       
        return INSTANCE;
    }

   
}
 
Deine Anforderung die du stellst ist etwas widerspruechig. Du sagst du willst nur eine Instanz in deinem gesamten Programm von dieser Klasse haben, aber du willst diese entweder "leer" oder mit einer Liste initialisieren. Also das widersprecht sich meiner Meinung nach etwas, weil wenn es nur eine Instanz gegebn darf, wieso willst du diese dann auf zwei unterschiedliche Arten instanzieren koennen.

Wenn du willst dass diese Instanz immer diese Liste haelt, dann musst du diese beim instanzieren angeben und verwenden. Wenn du willst das diese eine Instanz eine Liste halten soll, dann willst du diese auf der Instanz setzbar haben. Das widerspricht dann aber wieder ein wenig der "eine Instanz dieser Klasse" Sache, weil du diese ja offensichtlich mehrmals fuer unterschiedliche Dinge verwenden willst. Also irgendwo hakt da noch etwas.
 
Generell ist das ein Szenario, das so schwer umzusetzen ist. Was ist das denn für ein Parameter? Und warum Singleton? Das sieht so erst einmal (mit dem Beispiel) extrem dubios aus.

  • Bibliothek: Also es gibt ganz viele Bibliotheken. Daher ist eine Implementierung als Singleton so erst einmal grenzwertig. Mag ja sein, dass Du nur eine Bibliothek in Deinem Projekt hast / brauchst, aber diese Begrenzung im Code macht keinen Sinn.
  • Die Initialisierung ist dubios. Woher kommt denn die Liste der Bücher? Das ist ja etwas, das irgendwo her kommen kann. Das wäre dann eine Abhängigkeit, die es geben könnte.

Ein Ansatz, den es oft gibt, ist Dependency Injection. Dann hast Du dann ggf. auch sowas wie ein Singleton, aber das ist nicht im Code erzwungen. Und Du hast dann Abhängigkeiten. Das wäre dann sowas wie:
Java: 
@Component
public class Bibliothek {
    private List<Book> books;
    
    @Autowired
    public Bibliothek (AnfangBuchbestandSupplier bookSupplier) {
        books = bookSupplier.getBooks();
    }
}

Sowas in der Art habe ich auch scho einmal simuliert um eben keine DI Library einzubinden. Da habe ich dann eine Klasse ApplicationContext gebaut, die dann entsprechende "Beans" erstellt und herausgegeben hat. Da hatte ich dann (mehr oder weniger) das Singleton Pattern umgesetzt. Aber das war dann halt nur wirklich diese eine Klasse. Alle anderen Klassen hatten dann den Vorteil, dass ich diese beliebig testen konnte.
 
Jw456 hat gesagt.:
das wäre ein Grundgerüst
Java: 
public class ClassSingleton {

    private static ClassSingleton INSTANCE;
  
  
    private ClassSingleton() {     
    }
  
    public static ClassSingleton getInstance() {
        if(INSTANCE == null) {
            INSTANCE = new ClassSingleton();
        }
      
        return INSTANCE;
    }

  
}
Zum Vergrößern anklicken....
NEIN! wenn ihr sowas bringt, dann doch bitte vernünftig! Das ist kein brauchbares Singleton-Pattern! In einem multithreading Umfeld ist das schlicht falsch und unbrauchbar!

Siehe dazu ansonsten einfach eine der vielen Seiten wie z.B. https://www.learnbestcoding.com/post/11/thread-safe-singleton-design-pattern-example
(Einfach mal per Google gesucht und den ersten Treffer genommen)
 
frager2345 hat gesagt.:
Ah ok, ja das wäre eine Option. Dann hätte ich ja auch zwei instance methoden oder?
Zum Vergrößern anklicken....
jein.... das problem ist dass ein singleton einzigartigkeit ausdrückt und nicht für allgemeine zugänglichkeit genutzt werden soll

dh aber auch da es static ist du nicht weist in welchem zustand dein singleton ist, somit kannst du auch nicht entscheiden ob es richtig läuft in dem fall ( spaghetti code ) deswegen müsste dein singleton stateless sein dh nach dem benutzen genauso wie vorher sein
 
KonradN hat gesagt.:
NEIN! wenn ihr sowas bringt, dann doch bitte vernünftig! Das ist kein brauchbares Singleton-Pattern! In einem multithreading Umfeld ist das schlicht falsch und unbrauchbar!

Siehe dazu ansonsten einfach eine der vielen Seiten wie z.B. https://www.learnbestcoding.com/post/11/thread-safe-singleton-design-pattern-example
(Einfach mal per Google gesucht und den ersten Treffer genommen)
Zum Vergrößern anklicken....
also deine seite erklärt exakt dass das was er gemacht hat möglich ist, aber halt nicht thread safe... meine güte...

"hey ich möchte mein erstes singleton bauen"
"NEIN wenn dann vernünftig, muss thread safe sein braucht das, braucht jenes und dieses auch noch"
"OK"
 
KonradN hat gesagt.:
Das ist keine Anforderung. Ein singleton hat in der Regel auch einen veränderlichen State. Ansonsten wäre eine statische Utilitymethode oder so möglich. Oder habe ich Dich da jetzt missverstanden?
Zum Vergrößern anklicken....
Java: 
public class ClassSingleton {

    private static ClassSingleton INSTANCE;
 private int x;
 
    private ClassSingleton() {     
    }
 
    public static ClassSingleton getInstance() {
        if(INSTANCE == null) {
            INSTANCE = new ClassSingleton();
        }
      
        return INSTANCE;
    }
public int GetX(){
return x;
}

 
}
wenn das dein singleton ist und sonst nichts damit tust ( halt irgendwo setter )
hat man einfach nur eine statische variable auf dem komplexesten weg gebaut .. damit hat man nichts gewonnen und man ist wieder in static spaghetti code


wenn man zb einen xml parser als singleton implementiert und sagt der ist im state "noch nicht fertig" dann macht es halt schon sinn dass singleton einen state hat
 
Jw456 hat gesagt.:
von Threading war keine rede
Zum Vergrößern anklicken....
Sorry, aber das wird mir schlicht zu blöd. Natürlich muss der Code funktionieren und das machen, was man erwartet. Und Code der ggf. nicht richtig funktioniert, der ist schlicht falsch.

yfons123 hat gesagt.:
also deine seite erklärt exakt dass das was er gemacht hat möglich ist, aber halt nicht thread safe... meine güte...
Zum Vergrößern anklicken....
Ja, er erklärt, dass der Code, der da gezeigt wurde, ein großes Problem hat und dass es Wege gibt, wie man es richtig macht.

Auf welches Niveau wollt ihr hier gehen? Das Singleton Pattern ist nun wirklich nicht komplex. Das kann man richtig machen!

Aber ist ok, das Thema Kindergarten hatten wir ja schon ... Und Ihr könnt gerne machen, was Ihr wollt.
 
yfons123 hat gesagt.:
Java: 
public class ClassSingleton {

    private static ClassSingleton INSTANCE;
 private int x;
 
    private ClassSingleton() {    
    }
 
    public static ClassSingleton getInstance() {
        if(INSTANCE == null) {
            INSTANCE = new ClassSingleton();
        }
     
        return INSTANCE;
    }
public int GetX(){
return x;
}

 
}
wenn das dein singleton ist und sonst nichts damit tust ( halt irgendwo setter )
hat man einfach nur eine statische variable auf dem komplexesten weg gebaut .. damit hat man nichts gewonnen und man ist wieder in static spaghetti code


wenn man zb einen xml parser als singleton implementiert und sagt der ist im state "noch nicht fertig" dann macht es halt schon sinn dass singleton einen state hat
Zum Vergrößern anklicken....
Sorry, aber ich verstehe schlicht nicht, was Du sagen willst. Aber ist auch egal - macht ihr mal....
 
Java: 
Lazy initialization

A singleton implementation may use lazy initialization, where the instance is created when the static method is first invoked. If the static method might be called from multiple threads simultaneously, measures may need to be taken to prevent race conditions that could result in the creation of multiple instances. The following is a thread-safe implementation, using lazy initialization with double-checked locking, written in Java. In order to avoid the synchronization overhead while keeping lazy initialization with thread safety, the preferred approach in Java is to use the initialization-on-demand holder idiom.[citation needed]

public class Singleton {

    private static volatile Singleton instance = null;

    private Singleton() {}

    public static Singleton getInstance() {
        if (instance == null) {
            synchronized(Singleton.class) {
                if (instance == null) {
                    instance = new Singleton();
                }
            }
        }

        return instance;
    }
}
en.wikipedia.org

Singleton pattern - Wikipedia

en.wikipedia.org en.wikipedia.org
augenmerk auf "thread safe" bei lazy initalization
 
yfons123 hat gesagt.:
mach halt einen private setter für dein objekt und deine instance methode erwartet einen wert für den setter der dann instance aufruft, und zusätzlich hast du noch die alte instance methode die keinen parameter erwartet falls du singleton mit dem alten wert aufrufen willst aber dann ist man glaub ich bei spaghetti code ...
Zum Vergrößern anklicken....

KonradN hat gesagt.:
Generell ist das ein Szenario, das so schwer umzusetzen ist. Was ist das denn für ein Parameter? Und warum Singleton? Das sieht so erst einmal (mit dem Beispiel) extrem dubios aus.

  • Bibliothek: Also es gibt ganz viele Bibliotheken. Daher ist eine Implementierung als Singleton so erst einmal grenzwertig. Mag ja sein, dass Du nur eine Bibliothek in Deinem Projekt hast / brauchst, aber diese Begrenzung im Code macht keinen Sinn.
  • Die Initialisierung ist dubios. Woher kommt denn die Liste der Bücher? Das ist ja etwas, das irgendwo her kommen kann. Das wäre dann eine Abhängigkeit, die es geben könnte.

Ein Ansatz, den es oft gibt, ist Dependency Injection. Dann hast Du dann ggf. auch sowas wie ein Singleton, aber das ist nicht im Code erzwungen. Und Du hast dann Abhängigkeiten. Das wäre dann sowas wie:
Java: 
@Component
public class Bibliothek {
    private List<Book> books;
   
    @Autowired
    public Bibliothek (AnfangBuchbestandSupplier bookSupplier) {
        books = bookSupplier.getBooks();
    }
}

Sowas in der Art habe ich auch scho einmal simuliert um eben keine DI Library einzubinden. Da habe ich dann eine Klasse ApplicationContext gebaut, die dann entsprechende "Beans" erstellt und herausgegeben hat. Da hatte ich dann (mehr oder weniger) das Singleton Pattern umgesetzt. Aber das war dann halt nur wirklich diese eine Klasse. Alle anderen Klassen hatten dann den Vorteil, dass ich diese beliebig testen konnte.
Zum Vergrößern anklicken....
Ja, Singelton weil es gefordert war. Bin auch kein fan davon, aber muss es leider machen 🙁
 
wahrscheinlich ist der sinn der sache das ganze ding mal auszuprobieren ( thread safe ausprobieren natürlich 🙂 * SCNR * )
 
Jw456 hat gesagt.:
das wäre eine Möglichkeit beachte aber Konrads Thread Sicherheit die dein Code ja nicht hat .

wenn du das für deine Aufgabe brauchst .
Zum Vergrößern anklicken....
Würde ich den Setter dann in der Methode aufrufen? Aber müsste ich dann zwei Methoden schrieben, weil ich ja auch eine brauche wenn nichts übergeben wird, oder wie genau mach ich dies? Hab es noch ncith ganz verstanden 🙁
 
frager2345 hat gesagt.:
Würde ich den Setter dann in der Methode aufrufen? Aber müsste ich dann zwei Methoden schrieben, weil ich ja auch eine brauche wenn nichts übergeben wird, oder wie genau mach ich dies? Hab es noch ncith ganz verstanden 🙁
Zum Vergrößern anklicken....
du kannst das prinzipiell machen wie du lustig bist... solange es geht why not..

irgendwann lernt man es besser oder man bruachts anders und dann ändert es sich wieder
 
Du musst erst einmal genau sagen, was Du denn erwartest. Eine Möglichkeit wäre, dass Du einen Lazy Loading Ansatz fährst. Dann kann man z,B. einen Wert setzen, ehe man das erste Mal zugreift.

Das wäre dann also ein Ansatz wie:
Java: 
public class Bibliothek {
    private static volatile Bibliothek instance; // Single instance
    
    private static Collection<Buch> initialBooks; // Initial setting.
    
    public static void setInitialBooks(Collection<Buch> initialBooks) {
        if (instance != null) {
            throw new IllegalStateException("Instance already set!");
            Bibliothek.initialBooks = initialBooks;
        }
    }
    
    private Bibliothek() {
        // use initialBooks for initialization in here if not null!
    }
    
    public Bibliothek getInstance() {
        // Singleton lazy initialization if required ...
    }
}

Ich habe da jetzt einiges weggelassen um den eigentlichen Code übersichtlicher zu machen.

Hier hättest Du die Möglichkeit, vor dem ersten getInstance() Aufruf die initialen Bücher zu setzen. Wenn die Instanz aber einmal gesetzt ist, dann gibt es nur noch eine Exception.

Die Liste der initialen Bücher würde ich auch nicht direkt nehmen sondern die Elemente einfach übernehmen. Daher auch Collection - da kannst Du also alles nehmen... Und dann würde bei der neu erzeugten List ein addAll aufgerufen. (Das nur als Idee. Muss man nicht zwingend machen!)
 
yfons123 hat gesagt.:
du kannst niemals die intial books setzen
Zum Vergrößern anklicken....
Was bitte hast Du nicht verstanden? Du hast selbst on #17 die lazy initialization aufgezeigt...

Probiere es doch einfach aus. Beschäftige Dich damit! Ich weiss gerade nicht, was ich da sonst dazu schreiben soll. Muss ich eine komplette Implementierung mit Unit Test beistellen?
 
KonradN hat gesagt.:
Was bitte hast Du nicht verstanden? Du hast selbst on #17 die lazy initialization aufgezeigt...

Probiere es doch einfach aus. Beschäftige Dich damit! Ich weiss gerade nicht, was ich da sonst dazu schreiben soll. Muss ich eine komplette Implementierung mit Unit Test beistellen?
Zum Vergrößern anklicken....
Ach, jetzt sehe ich was Du meintest ... die Zeile ist hier im Forum in die geschweiften Klammern gerutscht.... das sollte natürlich ein:

Java: 
    public static void setInitialBooks(Collection<Buch> initialBooks) {
        if (instance != null) {
            throw new IllegalStateException("Instance already set!");
        }
        Bibliothek.initialBooks = initialBooks;
    }
sein.

passiert leicht mal, wenn man im Forum schreibt, aber das ist doch eigentlich offensichtlich gewesen, oder?
 
ich habe probiert
mag nich
EDIT: zeitgleich geschrieben
 

Anhänge

  • Screenshot (1).png
    Screenshot (1).png
    171,5 KB · Aufrufe: 3
Dass eine Bibliothek nur einmal erzeugt werden kann (parametrisiert oder nicht), ist doch überhaupt keine Anforderung, die die Bibliotheks-Klasse selbst lösen soll.
Sorry, aber so ein Unsinn, der hier gerade vorgeschlagen wird, basierend auf einer Reihe von Annahmen, die hier getroffen werden darüber, was der OP eigentlich genau will, habe ich selten gesehen.
Die Verantwortlichkeit muss beim Aufrufer/Client liegen, wie viele und welche Bibliotheks-Instanzen er erzeugen will und womit... Jetzt sieht es so aus, als möchte man die Bilbiotheks-Klasse selbst davor schützen, dass sie mehrmals erzeugt wird, weil der Aufrufer das anscheinend nicht kann. Aber warum denn?
Zumal es jetzt ziemlich unmöglich wird, die Bibliothek-Klasse zu unit-testen.
Wenn der Client/Aufrufer nicht weiß, wie man eine Instanz einer Klasse erzeugt und dann nur diese eine Instanz überall verwendet, dann kann man ihm wirklich nicht helfen und er soll vielleicht eher ein Dependency Injection Framework verwenden.

Die Responsibility, dass die Klasse nur einmal erzeugt werden können soll, ist keine der Bibliothek-Klasse, sondern eher ein Problem der Orchestrierung im Client/Aufrufer.
 
KonradN hat gesagt.:
aber das ist doch eigentlich offensichtlich gewesen, oder?
Zum Vergrößern anklicken....
genauso wie du es in #9 geschrieben hast habe ich dir es geschrieben..

hab dir den fehler genannt und warum das so ist

hats dir weitergeholfen? nein hat es nicht.. man hätte es anders sagen können und dann mehr erreichen können
aber ich bin dir nicht böse nur ich ziehe gerne menschen auf 😀

ich habe heute seit langem wieder was thread sicheres angeschaut... das war schon lange nicht mehr
 
yfons123 hat gesagt.:
genauso wie du es in #9 geschrieben hast habe ich dir es geschrieben..

hab dir den fehler genannt und warum das so ist

hats dir weitergeholfen? nein hat es nicht.. man hätte es anders sagen können und dann mehr erreichen können
aber ich bin dir nicht böse nur ich ziehe gerne menschen auf 😀

ich habe heute seit langem wieder was thread sicheres angeschaut... das war schon lange nicht mehr
Zum Vergrößern anklicken....
Sorry, aber in #5 wurde etwas gebracht, das man viel zu oft sieht und das schlicht falsch ist. Da kann man auch nicht sagen "Multi Threading war keine Anforderung". Mit der Aussage kann man auch sagen: Da will jemand ja nur paar SQL Befehle Absetzen. Sicherheit von SQL Injection war keine Anforderung. Das ist eine Argumentation, die einfach auch extrem daneben ist!

Und nur zum Verständnis, warum ich darauf poche: Wenn man hier falsche Dinge macht, dann rennt man eben in Produktion in ganz blöde Situationen, dass hin und wieder Fehler auftreten, die man nie nachvollziehen können wird. Bei einem selbst funktioniert es, alle Unit Test laufen und und und ... Daher ist es aus meiner Sicht wichtig, dass man hier so Dinge von Anfang an wirklich richtig macht! (Und dazu gab es auch schon mehr wie genug Threads!)

Und was mich vor allem getriggert hat: Der Code hat rein gar nichts beigetragen, denn das Singleton Pattern war nie an sich gefragt. Der TE hat in #1 bereits in seiner Methode instance() genau diesen Aufbau gezeigt. Und da frage ich mich: Liest man denn überhaupt, was der TE geschrieben hat?

Und das findet man hier im Forum ständig. Da werden Antworten ständig wiederholt (wie man es in anderen Threads ständig sieht). Was soll das denn? Also mich nervt das schlicht.

Und in dieser Phase kommen dann auch Antworten wie #27. Deine Antwort in #26 ist ja prinzipiell in Ordnung - Da hätte ich weniger genervt auch eher anders reagiert und genauer hingeschaut. Nur eben habt Ihr aus meiner Sicht den Vogel vorher abgeschossen ...
 
dann ist es ja geklärt 😀

ich fühle mich wie in fallout wenn man gegen eine horde zombies gekämpft hat und sich nur denkt "ein ganz normaler tag im java forum"
 
Java: 
public class Singleton {
    
    private static Singleton instance;

    private Singleton() {

    }

    public static Singleton getInstance() {
        if (instance == null) {
            instance = new Singleton();
        }
        return instance;
    }
}
 
timjoseph hat gesagt.:
Java: 
public class Singleton {
   
    private static Singleton instance;

    private Singleton() {

    }

    public static Singleton getInstance() {
        if (instance == null) {
            instance = new Singleton();
        }
        return instance;
    }
}
Zum Vergrößern anklicken....
Und genau das hatten wir schon inkl. Diskussion, wieso dies schlecht / falsch ist sowie dem Hinweis, dass dies nicht das Problem vom TE löst.
 
Java: 
public enum Singleton {
   
    INSTANCE;

    public void doSomething() {
        //...
    }
}
Löst allerdings auch nicht das Problem des TE...
 
Jw456 hat gesagt.:
Warum das gepostet wird erschliesst sich micht.
Zum Vergrößern anklicken....
Vermutlich weil es eine gute Singleton-Implementierung ist, die in diesem Thread bis dahin noch nicht vorgeschlagen wurde. Bei google books sieht man, was Bloch dazu schreibt. Das ist allerdings nur die zweite Auflage. In der dritten bezeichnet er es nicht mehr als "die beste" sondern nur noch als "oft die beste" Möglichkeit.
 
Das Thema kocht ganz schön hoch. Dann will ich mal (m)eine Lösung in den Ring werfen:
Java: 
public class Singleton {
    
    private Singleton() {
    }

    private static class LazyOwner {
        static final Singleton INSTANCE = new Singleton();
    }

    public static Singleton getInstance() {
        return LazyOwner.INSTANCE;
    }
    
}
Das Vorgehen hat sich bewährt und sollte threadsicher sein. Die Instanz wird beim ersten beim Zugriff erzeugt. Ich glaube das nennt sich "
init-on-demand" oder so ähnlich.
 
Das Problem mit dem Parameter gibt es gar nicht, man kann das ganz simpel mit 'delegate' erledigen:
Java: 
package playground;

import java.util.ArrayList;
import java.util.Collection;
import java.util.List;
import java.util.function.Consumer;
import java.util.stream.Stream;

public class Library {
    
    private final List<Book> books;
    
    private Library() {
        this.books = new ArrayList<>();
    }

    private static class LazyOwner {
        static final Library INSTANCE = new Library();
    }

    public static Library getInstance() {
        return LazyOwner.INSTANCE;
    }

    public void forEach(Consumer<? super Book> action) {
        this.books.forEach(action);
    }

    public int size() {
        return this.books.size();
    }

    public boolean contains(Book o) {
        return this.books.contains(o);
    }

    public boolean add(Book e) {
        return this.books.add(e);
    }

    public boolean remove(Book o) {
        return this.books.remove(o);
    }

    public boolean containsAll(Collection<Book> c) {
        return this.books.containsAll(c);
    }

    public boolean addAll(Collection<? extends Book> c) {
        return this.books.addAll(c);
    }

    public boolean addAll(int index, Collection<? extends Book> c) {
        return this.books.addAll(index, c);
    }

    public boolean removeAll(Collection<Book> c) {
        return this.books.removeAll(c);
    }

    public Book get(int index) {
        return this.books.get(index);
    }

    public Book set(int index, Book element) {
        return this.books.set(index, element);
    }

    public void add(int index, Book element) {
        this.books.add(index, element);
    }

    public int indexOf(Book o) {
        return this.books.indexOf(o);
    }

    public int lastIndexOf(Book o) {
        return this.books.lastIndexOf(o);
    }

    public List<Book> subList(int fromIndex, int toIndex) {
        return this.books.subList(fromIndex, toIndex);
    }

    public Stream<Book> stream() {
        return this.books.stream();
    }
       
}
 
temi hat gesagt.:
Dann hätte er aber seine eigene Antwort in #5 auch gleich hinterfragen sollen...
Zum Vergrößern anklicken....
Haha ... Ist das jetzt ein Test? ... Wenn ich Dir jetzt sage, dass ich mich hier im Thread sehr zurück gehalten habe, dann wirst Du mir nicht glauben, da ich ja auch durchaus Kritik gebracht habe und weniger zurückhaltend / freundlich war .... Aber ich habe sehr viele Gedanken und Hinweise für mich behalten 🙂

Dein Beitrag sehe ich auch nicht kritisch sondern sehr positiv. Du hast selbst geschrieben, dass es das Problem vom TE nicht löst, aber das Singleton Pattern war ja innerhalb des Threads mehrfach angerissen worden und - da stimme ich mit Dir und @Meniskusschaden zu 100% überein: Das ist (in Java) zumindest eine sehr gute Variante des Singletons! Dein Beitrag war also auf jeden Fall positiv und hätte ich nicht noch so viele Holzsplitter im Mund gehabt (vom in die Tischplatte beißen) hättest du vermutlich gestern schon ein Like dafür bekommen von mir.

Mit meinem Hinweis habe ich nur kurz beschrieben, was ich in der Aussage / Frage von @Jw456 lese.
 
In #5 habe ich ein nicht Thread sicheres Gerüst geliefert. Wie es der TE auch hatte. In #8 habe ich den zweiten Konstruktor hinterfragt der für mich keinen Sinn macht. Da wäre es wohl sinnvoller eine Arraylist als Instanzvariable in der Klasse zu halten und mit Setter Getter und Adder... die Liste zu bearbeiten.
Ein zweiter Konstucktor hat für mich in einen Singleton michts zu suchen. Das mit der Thread Scherheit lassen wir mal ausen vor.

Denn er will sicherlich die Liste aus mehreren Klassen heraus immer die gleiche Liste nutzen.


Es wird wohl eine Aufgabe gewesen sein es mit einen Singleton machen zu müssen.
 

Aktuelle Jobs

Neue Themen

Ähnliche Themen

Singleton und Singleton mit Instanz zu anderer Klasse -Pattern
Antworten: 30
Wie neue Instanz einer Klasse erstellen, von der ich nur eine andere Instanz kenne?
Antworten: 13
Wie erstelle ich eine Instanz in einer Klasse für die ich die Instanz will?
Antworten: 4
Instanz einer Klasse in einer anderen klasse erzeugen
Antworten: 3
Instanz(en) einer Singleton-Klasse
Antworten: 11

Zurück
Oben