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

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:
Y

yfons123

Gast
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 ...
 

frager2345

Aktives Mitglied
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 ...
Ah ok, ja das wäre eine Option. Dann hätte ich ja auch zwei instance methoden oder?
 

temi

Top Contributor
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 ...
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.
 

Jw456

Top Contributor
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;
    }

   
}
 

Robert Zenz

Top Contributor
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.
 

KonradN

Super-Moderator
Mitarbeiter
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.
 

KonradN

Super-Moderator
Mitarbeiter
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;
    }

  
}
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)
 
Y

yfons123

Gast
Ah ok, ja das wäre eine Option. Dann hätte ich ja auch zwei instance methoden oder?
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
 

Jw456

Top Contributor
Y

yfons123

Gast
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)
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"
 
Y

yfons123

Gast
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?
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
 

KonradN

Super-Moderator
Mitarbeiter
von Threading war keine rede
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.

also deine seite erklärt exakt dass das was er gemacht hat möglich ist, aber halt nicht thread safe... meine güte...
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.
 

KonradN

Super-Moderator
Mitarbeiter
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
Sorry, aber ich verstehe schlicht nicht, was Du sagen willst. Aber ist auch egal - macht ihr mal....
 
Y

yfons123

Gast
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;
    }
}
augenmerk auf "thread safe" bei lazy initalization
 

frager2345

Aktives Mitglied
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 ...

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.
Ja, Singelton weil es gefordert war. Bin auch kein fan davon, aber muss es leider machen :(
 
Y

yfons123

Gast
wahrscheinlich ist der sinn der sache das ganze ding mal auszuprobieren ( thread safe ausprobieren natürlich :) * SCNR * )
 

frager2345

Aktives Mitglied
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 .
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 :(
 
Y

yfons123

Gast
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 :(
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
 

KonradN

Super-Moderator
Mitarbeiter
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!)
 

KonradN

Super-Moderator
Mitarbeiter
du kannst niemals die intial books setzen
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

Super-Moderator
Mitarbeiter
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?
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?
 
Y

yfons123

Gast
ich habe probiert
mag nich
EDIT: zeitgleich geschrieben
 

Anhänge

  • Screenshot (1).png
    Screenshot (1).png
    171,5 KB · Aufrufe: 3

httpdigest

Top Contributor
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.
 
Y

yfons123

Gast
aber das ist doch eigentlich offensichtlich gewesen, oder?
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 :D

ich habe heute seit langem wieder was thread sicheres angeschaut... das war schon lange nicht mehr
 

KonradN

Super-Moderator
Mitarbeiter
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 :D

ich habe heute seit langem wieder was thread sicheres angeschaut... das war schon lange nicht mehr
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 ...
 
Y

yfons123

Gast
dann ist es ja geklärt :D

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"
 

timjoseph

Mitglied
Java:
public class Singleton {
    
    private static Singleton instance;

    private Singleton() {

    }

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

KonradN

Super-Moderator
Mitarbeiter
Java:
public class Singleton {
   
    private static Singleton instance;

    private Singleton() {

    }

    public static Singleton getInstance() {
        if (instance == null) {
            instance = new Singleton();
        }
        return instance;
    }
}
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.
 

temi

Top Contributor
Java:
public enum Singleton {
   
    INSTANCE;

    public void doSomething() {
        //...
    }
}
Löst allerdings auch nicht das Problem des TE...
 

Meniskusschaden

Top Contributor
Warum das gepostet wird erschliesst sich micht.
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.
 

Oneixee5

Top Contributor
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.
 

Oneixee5

Top Contributor
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();
    }
       
}
 

KonradN

Super-Moderator
Mitarbeiter
Dann hätte er aber seine eigene Antwort in #5 auch gleich hinterfragen sollen...
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.
 

Jw456

Top Contributor
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.
 
Ähnliche Java Themen
  Titel Forum Antworten Datum
frager2345 Java Singleton Muster -> Methode für Konstruktor mit Parametern Java Basics - Anfänger-Themen 3
J Implementierung von Observer und Singleton-Pattern Java Basics - Anfänger-Themen 9
W Sinn eines Singleton ? Java Basics - Anfänger-Themen 14
O Singleton Java Basics - Anfänger-Themen 5
R Methode in Singleton Klasse Java Basics - Anfänger-Themen 1
O Singleton Verständnis Java Basics - Anfänger-Themen 4
A Klasse,Vererbung,Interface,Singleton,Thread Java Basics - Anfänger-Themen 5
S Singleton (Design Patterns) Java Basics - Anfänger-Themen 16
R OOP Singleton Java Basics - Anfänger-Themen 10
U Vererben von Singleton Java Basics - Anfänger-Themen 17
S Singleton - Daten einspielen Java Basics - Anfänger-Themen 5
K Warum ist ein Singleton kein Best Practise? Java Basics - Anfänger-Themen 3
M Singleton mit Parametern im Konstruktor Java Basics - Anfänger-Themen 18
D Singleton beim JFrame zerstören Java Basics - Anfänger-Themen 4
L Java Serialisierung Singleton Java Basics - Anfänger-Themen 6
A JBoss-Anwendung soll im Singleton-Mode laufen Java Basics - Anfänger-Themen 6
Luk10 Problem mit Singleton bzw statischer Referenz! Java Basics - Anfänger-Themen 16
S Instanz(en) einer Singleton-Klasse Java Basics - Anfänger-Themen 11
S Statische Klassen/ Singleton Java Basics - Anfänger-Themen 13
J Warum verwendet man Singleton? Java Basics - Anfänger-Themen 7
B Was ist der unterschied zwischen Singleton und Strategy? Java Basics - Anfänger-Themen 6
S Singleton lazy Java Basics - Anfänger-Themen 8
A ist das ein Singleton-Pattern? Java Basics - Anfänger-Themen 6
P Singleton-Implementation Java Basics - Anfänger-Themen 8
F singleton Java Basics - Anfänger-Themen 4
T Singleton Java Basics - Anfänger-Themen 13
Antoras Singleton oder Controller / Datenverwaltungsklasse? Java Basics - Anfänger-Themen 10
D Objekte anlegen und Singleton Pattern Java Basics - Anfänger-Themen 21
D Denkfehler Singleton Java Basics - Anfänger-Themen 53
X Singleton - In diesem Fall sinnvoll? Java Basics - Anfänger-Themen 22
S Fragen zu synchronized + Singleton! Java Basics - Anfänger-Themen 10
M Singleton Pattern Java Basics - Anfänger-Themen 35
J Singleton Pattern Java Basics - Anfänger-Themen 5
S Singleton Pattern passend hierfür? Java Basics - Anfänger-Themen 60
M Mp3 Player mit Singleton Java Basics - Anfänger-Themen 8
M GUI als SingleTon Java Basics - Anfänger-Themen 6
B Singleton und Resourcebundle Java Basics - Anfänger-Themen 7
G Singleton Pattern Java Basics - Anfänger-Themen 7
D Singleton in Java implementieren Java Basics - Anfänger-Themen 6
H singleton Synchronisations Problem? Java Basics - Anfänger-Themen 2
M Singleton verwenden, aber wie? Java Basics - Anfänger-Themen 3
H Singleton mit Attributen Java Basics - Anfänger-Themen 7
E Durch Muster in Array iterieren Java Basics - Anfänger-Themen 3
B Dekorator Muster - Irgendwas stimmt hier doch nicht? Java Basics - Anfänger-Themen 4
1 Wie dieses Muster am einfachsten erkennen? Java Basics - Anfänger-Themen 32
H Muster mit verschachtelten Schleifen kreieren. Java Basics - Anfänger-Themen 2
Yasemin bahar Muster erkennen Java Basics - Anfänger-Themen 13
C Erste Schritte Muster ausgeben in der Konsole - großes V Java Basics - Anfänger-Themen 5
U Muster in einem Array erkennen Java Basics - Anfänger-Themen 8
F Quadrat Mit Muster Java Basics - Anfänger-Themen 15
J Muster und Schleifen Java Basics - Anfänger-Themen 33
R 2D Arrays mit vorgegebenem Muster Java Basics - Anfänger-Themen 2
E Arrays nach best Muster füllen Java Basics - Anfänger-Themen 4
K String nach bestimmtem Muster parsen Java Basics - Anfänger-Themen 3
P Sägezahn Muster Programm Java Basics - Anfänger-Themen 2
C Array Muster erzeugen Java Basics - Anfänger-Themen 2
J Erste Schritte zweidimensionales Array Muster befüllen. Java Basics - Anfänger-Themen 4
J Strukturierung mit MVC Muster Java Basics - Anfänger-Themen 20
J Array Muster mit true und false Java Basics - Anfänger-Themen 6
C Muster programmieren Java Basics - Anfänger-Themen 4
C Muster programmieren Java Basics - Anfänger-Themen 4
E Muster auf der Konsole ausgeben lassen (Schleifen) Java Basics - Anfänger-Themen 7
arti28 Erste Schritte For-Schleifen und While-Schleifen, String als Muster ausgeben. Java Basics - Anfänger-Themen 3
L Java Muster Java Basics - Anfänger-Themen 1
Todesbote String auf Muster überprüfen Java Basics - Anfänger-Themen 19
C Array Zickzack Muster Java Basics - Anfänger-Themen 3
P RegEx Muster mehrfach treffen Java Basics - Anfänger-Themen 2
M Muster erkennen. Idee: Fassade. Java Basics - Anfänger-Themen 3
Dit_ Regex | Muster {a}{b}{c} Java Basics - Anfänger-Themen 7
pindakaas Compiler geht nicht (Dekorator Muster) Java Basics - Anfänger-Themen 18
M Datentypen Strings nach Muster auslesen und verarbeiten Java Basics - Anfänger-Themen 5
S X Zeichnen als Muster ausgeben Java Basics - Anfänger-Themen 5
R Muster ausgeben Java Basics - Anfänger-Themen 4
H Muster ausgeben Java Basics - Anfänger-Themen 25
G String auf Muster prüfen Java Basics - Anfänger-Themen 5
O useDelimiter / Muster im Parameter (Pattern) Java Basics - Anfänger-Themen 6
S OOP Warum gleiche Instanz der Klasse? (Factory-Muster) Java Basics - Anfänger-Themen 13
L Sägezahn Muster Java Basics - Anfänger-Themen 4
C Muster mit Zweidimensionalen Arrays Java Basics - Anfänger-Themen 18
0 Applet mit folgendem Muster erstellen Java Basics - Anfänger-Themen 12
P Fragen zum Observer Muster und Datenbanken Java Basics - Anfänger-Themen 2
Z Muster Java Basics - Anfänger-Themen 9
J nach Muster in String suchen Java Basics - Anfänger-Themen 4
O Java Kara geschweifte Klammern Java Basics - Anfänger-Themen 2
richis-fragen Mausrad logitech kann links und rechts klick wie in java abragen. Java Basics - Anfänger-Themen 15
XWing Java Klssenproblem Java Basics - Anfänger-Themen 4
R Umgebungsvariable java -cp gibt immer Java-Hilfe... Java Basics - Anfänger-Themen 3
farbenlos Csv Datei in Java einlesen Java Basics - Anfänger-Themen 18
F TableModelListener: java.lang.ArrayIndexOutOfBoundsException: 132 Java Basics - Anfänger-Themen 3
G Java 8 - Support-Ende Java Basics - Anfänger-Themen 7
T Java Weihnachtsbaum + Rahmen Java Basics - Anfänger-Themen 1
N Will mit Java anfangen Java Basics - Anfänger-Themen 13
Ü Java Array - Buchstaben als Zahlen ausgeben Java Basics - Anfänger-Themen 22
M Java Iterator Verständnisfrage Java Basics - Anfänger-Themen 6
M Java Mail Programm Java Basics - Anfänger-Themen 4
Sniper1000 Java 391 für Windows Java Basics - Anfänger-Themen 37
J Java long- in int-Variable umwandeln Java Basics - Anfänger-Themen 6
JaZuDemNo Java im Studium Java Basics - Anfänger-Themen 7
E Java Programm zur anzeige, ob Winter- oder Sommerzeit herrscht Java Basics - Anfänger-Themen 62
I QR code in Java selber generieren Java Basics - Anfänger-Themen 5

Ähnliche Java Themen

Neue Themen


Oben