Keine Ahnung, welche Privatperson anruft und fragt,
wie sieht's aus, alles frei, na du weiß nicht, ja doch hier
komm, mach schnell kann ich nach Messe Coding Buddies Dein
Podcast rund um Softwareentwicklung und
aktueller Tech News. Herzlich Willkommen
einen wunderschönen guten Tag und herzlich Willkommen zur
neuen Folge vom Coding Buddies Podcast.
Fabi und Tino, also ich und Tino, Wir sind wieder am Start
bereit für ne neue Folge hoffe ich zumindest.
Tino bist bereit. Ich bin bereit.
Moin Fabi, Was geht ab, was geht ab, was geht ab, was geht, was
geht? Ja, was geht eigentlich alles
gut da ich. Dich das jede Woche Frage gibt
es auch nicht so viele News, immer dazwischen ne, es hat aber
einfach cool alles gut. Ja, ist schwer.
Wir müssen irgendwann mal, weißt du, wir machen irgendwann mal so
ne halbjährige Podcastpause ne und dann kannst du mich das noch
mal fragen, genau. Oder ich frag dich einfach ein
halbes Jahr lang nicht. Wir machen weiter folgen, aber
ich frag dich einfach nicht und du denkst dir jedes mal so,
warum fragt ihr nicht? Was ist los, du?
Willst gar nicht mehr wissen, wie es mir geht.
Mann, nein wir. Machen natürlich keine
halbjährliche Pause. Das ist natürlich alles Quatsch.
Es geht Schlach auf Schlag weiter, wir machen weiter, aber
bevor wir jetzt wirklich weitermachen, richtig
reinstarten wollte ich noch mal ganz kurz anmerken, Tino weil
Pass auf, man denkt ja, man weiß alles über Podcast, wenn man
selber einen Podcast macht, dann.
Aber so ist es nicht, weil es gibt, und das hab ich jetzt
erstmal richtig realisiert, in zum Beispiel bei Spotify oder
halt auch bei den anderen Plattformen.
Gibt es so ne Glocke und die kannst du anmachen, ne für n
Podcast und wenn du die Anmachst, dann kriegst du immer
ne notification wenn es ne neue Folge gibt.
Und ich dachte mir so. Okay sowas gibt es bei youtube
auch und so ne ja okay okay. Krass.
Und das ist krass und deswegen will ich einmal ganz kurz sagen,
Leute, wenn ihr das noch nicht angebracht habt, dann auf jeden
Fall diese Glocke anmachen beim Podcast, weil dann verpasst ihr
keine neue Folge. Und falls ihr noch nicht
abonniert habt, dann natürlich auch, weil dann ist es die
wahrscheinlich keine neue Folge zu verpassen, auch geringer.
Also Glocke anmachen, abonnieren, das ist wichtig.
Ey cool, dann können wir jetzt immer sagen, wenn du keine neue
Folge verpassen willst, dann drück auf die Glocke.
Ganz genau. Geil.
Keiner freut mich drauf. Das war ungefähr das, worauf ich
hinaus wollte und da würde ich sagen, lass uns doch jetzt mal
so ordentlich mal richtig ins Thema starten und zwar geht es
ja heute wieder um unsere neue Reihe, die wir letztens
gestartet haben, patterns ne die schönen Design Patterns in der
Softwareentwicklung. Wo welches Design Pattern haben
wir uns denn heute mal geschnappt?
Tino Worum? Geht es heute?
Heute haben wir, wie soll ich sagen, so n umstrittenes Pattern
ausgewählt, aber es ist eigentlich so 1 der allerersten
was man sich so anschaut, wenn man in den Bereich der Design
Patterns geht und zwar möchten wir heute Fabi und ich freue
mich drauf, wir möchten heute über singleten reden, über das
Design Pattern singleten und. Ich würde sagen, wir starten
mal. Du hast doch bestimmt ne
Analogie oder? Ich freue mich immer so riesig
auf deine Analogien und ich sehe es schon in deinen Augen, du
kannst das gar nicht abwarten, hau doch mal ne Analogie raus,
wie würdest du denn so Singleton umschreiben?
Pass auf, ich hole erstmal mein Analogie Märchenbuch heraus, da
muss ich erstmal. Suchen?
Nein, so heißt so Finger anlecken umblättern, so neue
Analogie also. Herrn Singleton, ich glaub man
kann da 1000 Analogien für bringen.
Wahrscheinlich. Ich stell mir das ganz gerne,
zum Beispiel so vor, dass wenn du n Theater hast ne, also stell
dir mal so n normales Theater vor, wie man das halt so kennt
ne und wir sind aber nicht in der Aufführung an sich, sondern
beim Proben ne, also du hast quasi du Probst entsprechende
Szenen und. Dann ist es ja im Normalfall so,
dass du vielleicht unter Umständen auch verschiedene
Szenen parallel proben kannst. Also du könntest ja zum Beispiel
3 Bühnen bauen oder irgendwie 3 Räume nehmen und da können
Leute, die in den entsprechenden Szenen halt sind, diese Szenen
eben proben. Wenn es jetzt aber irgendwie
Fragen gibt oder diese Szene bewertet werden soll, dann gibt
es halt am Ende einen Regisseur, ne, der am Ende sagt, OK, Pass
auf, mach du die Szene so, da musst du noch n bisschen was an
deiner Aussprache ändern und hier, das war mir zu wenig
Gestik und Mimik, also da mal n bisschen das ganze aufpeppen und
ich würde gern die Szene noch mal n bisschen ändern an der
Stelle ne das heißt es gibt einen Regisseur der allen.
Wenn jeder Szene, auf jeder Bühne oder in jedem Raum sagt,
wie sozusagen was gemacht werden soll, wie das ganze aussehen
soll, ne. Und wenn du jetzt dir überlegst,
dass du zum Beispiel sagen würdest, du hast jetzt 2
Regisseure, ne, und jetzt kommen die, ich weiß nicht Raum 1 ne wo
die Üben kommen zu Regisseur 1 und sagen, wie sollen wir das
denn machen, dann sagt er ja, mach das auf jeden Fall so
richtig trocken so, und dann machen die das trocken, dann
kommt Regisseur 2, guckt sich das an, denkt sich, was macht
ihr da für n Quatsch, ja, ihr sollt das mal so richtig peppig
machen, das muss richtig. Nicht abgehen so diese Szene.
Ne die ist das ist, das herrschte Geistwort so ne und
das heißt im Endeffekt wenn du jetzt 2 Regisseure hättest,
würde halt totales Chaos entstehen, weil du hast
unterschiedliche Ideen oder was auch immer, was du dann im
Endeffekt in diese entsprechenden Szenen
reinbringst und das kann man sich jetzt natürlich so
vorstellen. Ne, der Regisseur ist dann am
Ende des Singleton. Ne, also quasi eine
Kontrollinstanz, die sagt das und das und das soll passieren,
sozusagen die Source of Truth über bestimmte Abläufe
beispielsweise und die entsprechenden Szenen in den
entsprechenden Räumen sind verschiedene Teile der des
Programms, zum Beispiel ne so, aber alle brauchen den Input von
dem Regisseur. Genau das heißt jeder ja, also
so Schauspieler, die können ja untereinander reden und sich
austauschen oder so, aber wenn es darum geht, wirklich
Anweisungen zu kriegen oder die. Absolute Wahrheit.
Ja, wie du es gerade meintest, dann gehst du halt zum Regisseur
und fragst nach ne, das ist eigentlich n ganz cooles
Beispiel so n anderes Beispiel auch so n Klassiker wenn du
jetzt überlegst ich hab jetzt meine Software ist jetzt n
Flughafen oder so ja also ich nehm jetzt mal das Gedankenspiel
Ich bin auf dem Flughafen auf einen ne nicht jetzt weltweit
mit mehreren wir machen es nicht komplexer wir sind auf einem
Flughafen. Und um den Flugverkehr zu
steuern, hast du ja im Prinzip n Kontrollturm so n Tower ne und
da gibt es halt einen von. Ja, also ist ja nicht so, dass
jetzt jede jedes Flugzeug so verschiedene Tower anfunkt oder
keine Ahnung welche Privatperson anruft und fragt, wie sieht es
aus, alles frei na du weiß nicht, ja doch hier komm mach
schnell kann ich nach Messler. Und das ist, das kann man sich
ja auch so vorstellen, dass im Prinzip dieser Kontrollton auch
einzigartig ist in in Scope unserer Software oder des
Flughafens. Ja, und quasi immer angefragt
wird für Infos und es gibt ihn halt nur einmal.
Und genau diese Grundidee und dieses Prinzip verkörpert das
Single N Pattern. Ja, das heißt.
Mit dem Pattern sorgt man dafür, dass es genau eine Instanz einer
bestimmten Klasse gibt. Klasse Regisseur, Klasse
Kontrolltom, was auch immer, jetzt mal angepasst an unsere
Beispiele. Ja, und dass alle Teile des
Programms dann auf diese gemeinsame Instanz zugreifen,
richtig, ja, also das heißt, du Erzeugst eine Instanz und auch
nur eine und alle können gemeinsam diese Instanz
verwenden. Jetzt denkt sich vielleicht der
ein oder andere Leute, was ist das für n Pattern?
Das klingt total nach einer globalen Variable.
Ja, auch auf diesen Punkt werden wir eingehen in dieser Folge und
das Halt mal beleuchten, wie gut ist dieses Pattern, wofür kann
man es verwenden, jetzt wo wir es mal so grob abgesteckt haben
und warum ist es umstritten, hatte ich ja schon angedeutet,
das lass mal jetzt in dieser Folge bequatschen, Fabi und
natürlich auch, was gibt es denn zum Beispiel auch für
Alternativen, wenn man sagt, OK, es ist umstritten.
Hin, weil es bringt ja nichts, wenn man sagt, es ist
umstritten. Na ja, gut, aber du musst es
nehmen, natürlich auch blöd, aber das sind auf jeden Fall
wichtige Fragen, die wir jetzt in der Folge klären wollen.
Und um jetzt aber mal so n bisschen wegzugehen von den
entsprechenden Analogien, sondern mal wirklich hin zur
Technik und man sich vielleicht jetzt fragt, ja OK, aber was
bringt mir das ganze, wenn das alles Quatsch ist?
Also es gibt natürlich auch. Wirklich sinnvolle Sachen oder
oder Dinge wo ist wo so n Single oft genutzt wird, da gibt es
schon n paar Beispiele wie zum Beispiel jetzt ein Logger, ne
kann man sich so vorstellen. Also wenn du jetzt irgendwo n
Logger in deiner Software hast, dann macht es halt eben nicht so
viel Sinn wenn du sagst OK du hast jetzt weiß nicht du willst
in deiner Anwendung möchtest du sagen OK wir gehen jetzt auf n
bestimmtes Log level ne das hast du ja meistens so dass du n
logger hast wo du sagst OK ich kann irgendwie mir Infos
rausspucken ich kann mir aber auch.
Wirklich komplett sozusagen auf Debug das ganze Stellen, dass du
wirklich alle Informationen rausgeklatscht bekommst, die du
aber eigentlich als Anwender vielleicht gar nicht brauchst.
Ne, aber unter Umständen als Entwickler vielleicht schon oder
als Entwicklerin. Und wenn du jetzt aber n Logger
hast, der nicht, sag ich jetzt mal zum Beispiel in so einer
Singleton Instanz existiert. Dann würdest du zum Beispiel in
in dem einen Teil deiner Software beispielsweise den
Logger auf Info stellen und in dem anderen Teil deiner Software
hast du ne andere Instanz von diesem Logger, der aber dann auf
Debug steht und dann fragst du dich vielleicht, hey, ich hab
doch meinen Logger instanziiert und hab eine, also ne, ich hab
irgendwie n Logger in meiner Software, der auf der einen
Seite als in also info auf Info eingestellt ist.
Und jetzt krieg ich doch die ganze Zeit irgendwo ab in einem
bestimmten Teil krieg ich irgendwie debug Informationen ne
das ist. Beispielsweise so n so n Ding,
aber dir fällt bestimmt auch noch was ein, wenn es jetzt
nicht dran locker ist. Ja, was halt auch so n Klassiker
ist, ist so ne Art Konfigurationsmanager.
Wenn ich halt ne config habe in meiner Software ne und die soll
halt von allen möglichen Stellen ausgelesen werden, dann macht
das da auch Sinn, weil ich möchte ja nicht unterschiedliche
Konfigurationen rumgeistern haben, ne?
Sondern ich bau eine Instanz auf meiner Config und die kann halt
abgerufen werden von allen und immer die gleiche config.
Das wär halt auch n Beispiel wie gesagt, es gibt auch andere
Umsetzungsmöglichkeiten, aber es ist auf jeden Fall erstmal n
Anwendungsfall für n Singleton oder halt auch n Klassiker ist
auch so n Cash ne wenn ich sage ich möchte ne Art Cash haben der
sozusagen wirklich global ist. Ne dass ich halt zum Beispiel
Ergebnisse, Ergebnisse, Ergebnisse.
Zwischenspeicher und damit sie halt nicht mehrfach berechnet
werden oder mehrfach ausgeführt werden und ich kann dann wieder
aus diesem Cache diese Ergebnisse laden und dann
brauche ich natürlich auch die Gewährleistung, dass alle vom
gleichen Cache arbeiten. So ne Source Trust dann am Ende,
weil es bringt ja nichts wenn du was Cache und dann kriegst du
aber hinterher weiß ich nicht von einem anderen Cache n
Zwischenergebnis was du aber eigentlich gar nicht berechnet
hast. Folgefehler.
Ist dann kacke? Genau.
Das wär halt auch noch so n Anwendungsfall.
Genau. Also im Endeffekt ist es halt,
wird es halt wie gesagt oft da verwendet, wo man halt
irgendwie, sagen wir mal globale Zustände vielleicht braucht
speichern möchte und es jetzt vielleicht aber auch nicht.
Also da muss man natürlich auch noch n bisschen unterscheiden
zwischen einem Persistenten. Persistenten Speicherung oder so
einer flüchtigen Speicherung ne. Also wenn du sagen wir mal die
Software anschmeißt und so lange wie die Software lebt halt eben
auch oder läuft halt eben auch diesen Zustand speichern
möchtest. Ne.
Also sonst wäre zum Beispiel ne Datenbank irgendwas was du
nehmen könntest. Aber das ist es jetzt quasi
nicht. Wir sind jetzt quasi wirklich
nur rein in unserer Software unterwegs und schließen jetzt
nicht noch ne Datenbank an genau aber.
Genau. Also das ist auch schon n guter
Punkt, ne. Also n Singleton ist natürlich,
also es ist n. Ne Instanz eines einer Klasse,
die ja instanziiert wird zur Laufzeit der Software.
Das heißt du hast halt auch n abgesteckten Lebens ne
abgesteckte Lebenszeit, sozusagen ne.
Also wenn ich die Software beende quasi, dann ist das
natürlich weg, ne, also da haben wir jetzt nichts persistentes
also nur ist ne gute Anmerkung, dass wir da halt auch vom
richtigen Scope gerade reden. Ja genau, und genau wie du
meintest, wenn man so globale Zustände gemeinsam Ressourcen
oder so. Braucht, dann denkt man oft an
direkt an den Singleton das. Klingt ja auch schon.
Du hast ja auch gesagt, ja, globale Variablen.
Ne. Kann man daran denken, ist ja
auch irgendwo. Wie gesagt, kommen wir später
noch drauf zurück, wir sind ja auch jetzt schon, also wir sind
natürlich bei diesen ganzen Design pattern sind wir
natürlich schon irgendwie hart in einem in einem.
Im Objektorientierungskontext unterwegs, da hatten wir letztes
Mal auch so n bisschen bei der letzten Folge auch so n kleinen
Exkurs gemacht und ich würd diesmal auch wieder n kleinen
Exkurs machen, weil es schon glaub ich sinnvoll ist das
einmal in diesem Kontext gehört zu haben.
Ne und zwar über das über den das Schlüsselwort static ne und
weil gerade wenn du zum Beispiel mit so Singleton arbeitest hast
du meistens irgendwie dieses Wort Static mit drin in ne also
im. Größeren also ne, es gibt, ich
weiß jetzt nicht ob es vielleicht Sprachen gibt, wo
Static vielleicht anders heißt. Beispielsweise kann ja auch
sein, hab ich jetzt nicht im Kopf, deswegen will ich es jetzt
nicht ausschließlich auf Static runterbrechen, aber nur, dass
man ungefähr weiß worum es geht, ne und Static ist im Endeffekt
ich, ich versuch das noch mal wieder mit einer Analogie ne
wenn wenn du jetzt sagen wir mal du hast Häuser ne und Häuser
sind jetzt Objekte und die stehen alle in einer Straße ne
dann hat ja jedes Haus ne Hausnummer ne das heißt?
Das ist n Attribut, was an dem Haus hängt an dem Objekt Haus,
wo aber sich dieses Attribut unterscheidet, das heißt jedes
ein, jeder jede Instanz dieses Hauses bekommt eine eigene
Hausnummer, ne, das heißt, dass diese diese Hausnummer gilt
immer nur für ein Haus, für eine Instanz von Haus.
So ne jetzt hast du aber zum Beispiel noch ne Postleitzahl,
die ja wenn die Häuser zum Beispiel in der Gleichenstraße
stehen auch. Immer die gleiche Postleitzahl
ist, das heißt, rein theoretisch kannst du jetzt sagen,
Postleitzahl an sich ist Static für das Objekt Haus angenommen
die stehen alle in einer Stadt oder in einer Straße ne weil
diese Postleitzahl für dieses Haus halt einfach immer, also
für für für jede Instanz von Haus gleich ist.
Weißt du wenn du sagst ich instanziere instanziere ein
Haus, also ein Objekt der Klasse, dann kriegt dieses Haus
zwar eine. Hausnummer eine eigene, aber die
Postleitzahl, die musst du nicht immer noch mal zuweisen, weil
die ist halt einfach da. Das ist immer die gleiche so ne.
Also vorausgesetzt, dass du dieses Haus auch nur
instanziieren möchtest in einem Postleitzahlgebiet.
Ja genau. Das hab ich jetzt.
Also wir stecken. Das jetzt mal in den kleinen
Bereich? Ja nur nicht, dass jetzt jemand
denkt, dass es denn für alle gilt.
Also aber das wär n Anwendungsfall genau weil wenn
du sagst es gibt sozusagen kein Objekt Haus wo die Postleitzahl
anders ist, dann ist das. Ist ein statisch gegebener
Kontext am Ende genau und im Endeffekt ist es ja so, dass
quasi Static am Ende bedeutet, dass etwas nicht zu einem
einzelnen Ding gehört, sondern zu allen Dingen von dieser
Klasse sozusagen ne genau genau kurz zusammengefasst.
Das heißt, du musst kein Haus erzeugen, um auf die
Postleitzahl zuzugreifen? Genau, genau, genau.
Wie gesagt, immer in dem Scope jetzt angenommen, wir bleiben
natürlich in der gleichen Stadt, die Postleitzahl kann sich jetzt
nicht ändern. Ne, das war jetzt die kleine
Voraussetzung für diese Analogie, aber wenn wir das
ganze jetzt noch mal technischer machen, weil jetzt kann man sich
hinstellen, OK, ich versteh jetzt noch nicht warum das jetzt
n Singleton ist, weil du ja gerade gesagt hast, Fabian N
Haus kannst du instanzieren hast verschiedene Häuser mit
verschiedenen Hausnummern, ne so all das hast du.
Gerade gesagt, das ist richtig. Das hab ich gerade gesagt.
Nee, also natürlich ist das jetzt kein Single an sich, aber
das Wort Static oder dieses, dieses, dieses Schlüsselwort
static ist halt wichtig an der Stelle um überhaupt am Ende zum
Beispiel so n Single erzeugen zu können.
Ne genau und da können wir ja gleich mal so n bisschen jetzt
technischer drauf eingehen wie das also wieso n Single jetzt
quasi technisch aussieht, weil wir haben ja jetzt n Beispiel ne
Logger genannt und so weiter aber wie kann man das jetzt?
Genau. Also wir müssen ja jetzt quasi
sicherstellen, dass von einer Klasse zum Beispiel na, das
Haus, gehen wir mal n bisschen weg von dem Haus, weil da hast
du jetzt mehrere Instanziiert, ne, aber wenn wir jetzt wirklich
sagen, wir wollen jetzt die Klasse singleten, wir nennen sie
jetzt so richtig lehrbuchhaft singleten ja instanziieren und
wollen aber sicherstellen, dass es immer nur eine.
Instanz geben kann. Ja, das müssen wir jetzt
technisch gewährleisten und wie du ja gerade erklärt hast, gibt
es halt sozusagen ne globale Zugriffsmöglichkeit auf eine
Klasse über Static über den statischen Kontext sozusagen
oder scope so und typischerweise so Lehrbuchhaft machst du das
so, dass du die. Klasse den Konstruktor erstmal
private setzt ja also zum Beispiel jetzt in Java oder so
und das ist. Einfach deshalb macht man das,
damit du halt schon mal verhindern kannst, dass der
Coder oder der die Software halt programmiert, die Coderin keine
Instanzen davon erzeugen kann, weil der private ist halt der
Konstruktor, der ist nicht mehr public.
Das heißt, ich kann den nicht aufrufen von außen und ich kann
jetzt kein Haus erzeugen mehr oder Single in die Klasse haben
wir sie jetzt genannt, so dann ist schon mal der erste Schritt
gewährleistet, ich kann nicht beliebig viele erzeugen.
Aber das Ding ist, jetzt kann ich nicht mal eine erzeugen.
Ja, jetzt hab ich mich komplett ausgesperrt und jetzt kommt gut,
dass du es auch noch mal eingebaut hast, weil das hätte
ich jetzt zum Beispiel vergessen das Static mal zu erklären,
jetzt kommt halt der statische Aufruf die statische Methode
dazu, dass du halt ich glaub in Büchern heißt es meistens sowas
wie Get instance oder so ja also dass du halt ne statische
Methode bereitstellst, die quasi dir diese Instanz zurückgibt.
Genau ne, dass du halt ne Möglichkeit hast an eine Instanz
von Singleton ranzukommen. Und jetzt liegt da auch die
Pattern Logik drin, weil wenn du das jetzt einfach so machst,
kriegst du wieder so viel Instanz wie du willst.
Wenn du jetzt einfach Return New Singleton drin ist, dann ja nix,
nix gewonnen ja also das heißt diese Get instance Methode muss
ja jetzt dafür sorgen, dass wenn noch keine Instanz erzeugt
wurde. Mhm.
Eine Instanz erzeugt wurde genau von Singleton eine Instanz
erzeugt wird und zurückgegeben wird.
Und falls schon mal eine erzeugt wurde, genau die wieder
zurückgegeben wird und dann hast du nämlich genau diese diese
Pattern Logik abgebildet, erstmal in einem sehr einfachen
Stil. Es gibt da auch noch so ein 2
Probleme, die kannst du ja vielleicht gleich mal erläutern.
Aber dann hast du eine sehr einfache Logik implementiert, um
dieses Pattern abzubilden, weil dann kriegst du, wenn es noch
keine gibt, eine neue Instanz von Singleton und wenn es schon
eine gibt, dann kriegst du die, die schon mal erzeugt wurde, das
heißt, du speicherst dir quasi intern diese Instanz ab und
gibst die dann immer wieder zurück, es sei denn, es gibt
keine, musst du sie halt einmalig erzeugen, richtig?
Und das interessante an diesem Static oder diesem statischen,
dieser statischen Funktion ist ja, dass du im Endeffekt, sagen
wir mal, du bist in einem Objektorientierungskontext
unterwegs und möchtest eine Funktion auf einer Klasse
aufrufen, dann brauchst du ja erstmal eine Instanz dieser
Klasse, das heißt, du brauchst ja erstmal dieses New ne
normalerweise, um ein neues Objekt anzulegen, um dann
sozusagen auf diesem erstellten Objekt dann diese entsprechenden
Funktionen aufzurufen. Wenn du jetzt aber diesen diesen
statischen Kontext hast, dieses Static davor setzt, dann hast du
die Möglichkeit einfach auf. Der Klasse sozusagen ne diese
Funktion aufzurufen. Das heißt du brauchst keine
Instanz, sondern kannst einfach sagen, OK, ich möchte diese
Funktion aufrufen, das heißt du sagst dann sowas wie Singleton
Punkt, Get instance beispielsweise ne, ohne dass du
jetzt vorher sagen musst, New Singleton ist mein Singleton und
dann sag ich Singleton Punkt, also Singleton kleingeschrieben,
die variable Punkt get instance, das ist sozusagen hier so
nochmal der Unterschied, falls das jetzt noch nicht richtig
rübergekommen ist, ne. Das ist jetzt auf jeden Fall so.
Die klassische blazy Variante nennt man das Ganze, das heißt
du hast noch eventuell noch keine, kein Singleton und wenn
du 1 brauchst, dann holst du dir 1.
Und wenn du schon 1 da hast, dann halt eben nicht und.
Das kann natürlich aber jetzt sein, dass das vielleicht mit
Multi threading oder so noch nicht so richtig funktioniert.
Ne, musst du das ganze vielleicht noch synchronisieren
oder andere Mechanismen verwenden, um wirklich
sicherzustellen, dass du jetzt auch wirklich nur auf einer
Instanz unterwegs bist und nicht auf einmal?
Wichtiger Punkt genau, definitiv, also das ist auch im
Endeffekt so n bisschen so n wie sagt man so schon so ne kleine
Limitierung davon, ne, da muss man halt auch wirklich richtig
aufpassen, wenn es um Multi threading geht, ne?
Aber wie gesagt, das ist jetzt auf jeden Fall nicht unbedingt
Teil der Folge multistrailing oder?
Das Problem können wir aber gerne auch noch mal besprechen,
wenn es jemanden interessiert. Genau.
Und ja, das ist eigentlich so die klassische Implementierung,
oder? Genau.
Also so so, wenn ich es mal verwendet habe oder mal
programmiert habe ich es auch so gemacht.
Und es ist auf jeden Fall auch nicht verkehrt, das Mal
auszuprobieren, weil wie gesagt, in in in Pattern hat ja irgendwo
irgendwo seine Daseinsberechtigung, aber in dem
Fall ist es natürlich auch schon so, dass man beim Single so n
bisschen sagt, Na Singleton, das ist vielleicht auch nicht gerade
so die geilste Variante und das Beste.
Und mal, wir können ja mal n bisschen gucken, was oder wo man
vielleicht so n Single vielleicht lieber nicht
verwenden sollte und warum auch beispielsweise ne, also ich
weiß. Noch als wir damals im Studium
angefangen haben, Design Pattern, also Pattern, zu
lernen, ne, also hatten wir ja auch so in verschiedenen
Vorlesungen, und dann hat man es ja auch gecoded und gerade am
Anfang lernst du Design Patterns kennen, also auch vielleicht du,
liebe Zuhörer, liebe Zuhörer, falls du jetzt.
Dir gerade jetzt diese Folge anhörst und dir denkst, das
klingt geil, das ist, das kann ich jetzt echt oft verwenden, ne
und mir ging es damals so, ich weiß nicht wie es bei dir war,
fabi, ich hab das Ding kennengelernt und immer wenn ich
so n Pattern kennengelernt hab, dann hab ich es auch erstmal
überall verwendet gefühlt und beim Singleton das was oft
kritisiert wurde hat sich erstmal richtig angefühlt.
Weißt du, du hast halt ne einfache Möglichkeit Daten
überall bereitzustellen oder Funktion.
Ja dann sagt er Ja mach doch n Single draus, dann kannst du
doch überall aufrufen. Ja, aber genau das ist ja das
Problem, ne also in diese Falle zu tappen zu sagen nee jetzt
Kapsel ich alles in dieses Design Pattern und bau überall
also ich mach aus allen klassengefühl singletens ne und
dann bist du halt bei diesem was wir meinten.
Ja, was ist jetzt der Unterschied zu globalen
Variablen? Oder?
Dann kannst du einfach globale Funktionen haben oder sowas ne,
weil das ist genau das Problem, warum viele Leute das Pattern
nicht mögen oder sehr sehr umstritten betrachten.
Ja, das haben wir jetzt ja schon mehrfach erwähnt und das möchte
ich jetzt einfach mal kurz erläutern mit dir, denn Fakt ist
ja du erschaffst sehr schnell viele versteckte Abhängigkeiten.
Oder wie siehst du das? Ja.
Auf jeden Fall. Also ich find es gut, dass du
das Studium erwähnt hast, weil ich auch damals im Studium an n
Punkt gekommen bin, wo ich mir dachte es wär so geil, wenn ich
jetzt einfach nicht immer dieses, also ich bräuchte jetzt
eigentlich n Objekt was ich erzeuge und dann.
Kann es nicht noch mal 1 davon geben?
Also ich, dass ich immer das nehme und dann kam halt
irgendwann so, ja nimm doch n Single und ich dachte mir so
Alter, wie geil ist das denn, das ist ja.
Ist ja. Mein changing weißt du, weil ich
mir dachte, es kann doch nicht wahr sein, es gibt es geht, es
gibt da sogar n Pattern für das muss gut sein.
Also ich mein, wenn es dafür Begriff gibt in der Informatik,
dann ist es ja wohl der Knaller. So ne hab ich auch gemacht und
das und genau diese Abhängigkeiten von denen du
redest ne das ist find ich dann am Ende richtig richtig schwer
weil angenommen du hast. Dein Single Ne und du benutzt es
irgendwo an der einen Seite deiner Software und irgendwo auf
der anderen Seite deiner Software und du stellst
vielleicht irgendwas um ne in deinem in deinem Single und
denkst dir so in deinem Programmablauf.
Ja erstmal komme ich da durch und dann würde ich zum Beispiel
weiß nicht die und dieses Attribut beispielsweise auf den
Wert. X stellen und dann funktioniert
die Software mit dem Wert x und dann komme ich ja irgendwann an
die andere Stelle meines Codes und da muss ich die den das
Attribut aber auf Wert Y stellen, easy peasy gar kein
Problem und schon läuft die Bude und ich muss aber nicht noch
irgendwas anderes machen oder ich stell zum Beispiel dieses
Attribut anhand von dem vorherigen Wert um oder sowas
ne. Was auch immer, ne, also dass
ich sozusagen nicht von x statisch auf Y schalte, sondern
sage unter bestimmten Umständen, wenn es vorher x war, dann stell
ich aber hier das auf Y um in meinem nächsten Programmablauf
bedeutet aber, dass du in deinem Single irgendwo global etwas
änderst, was du mit hundertprozentiger Sicherheit an
einer anderen Stelle wieder vergisst.
Dieser Wert wieder genutzt wird und irgendein Quatsch in einer
Software passiert und du dir denkst, warum ist das gerade
passiert? Das sind genau diese
Abhängigkeiten, diese Verstecken, von denen du gerade
geredet hast. Und das zu Debacken und
hinterher zu schnallen, was da los ist.
Wenn du vielleicht gerade nicht unbedingt verstanden hast, wie
ich zum Beispiel damals, was so ein Singleton eigentlich macht
oder wo man es vielleicht nicht verwenden sollte oder was
vielleicht die Einschränkungen oder die Probleme damit sind,
dann bist du ewig dabei, deinen Code zu debacken, weil du dir
denkst, hä, was soll das ne, wo kommt das her, ja.
Du hast halt. Also die Versuchung ist extrem
groß, gerade am Anfang, wenn man mit dem Pattern arbeitet, halt
diese globalen Zustände auszunutzen oder es als Verein,
also es ist halt so easy Lunch am Anfang ne, weil du sagst, OK,
ich kann jetzt schnell ne Lösung damit basteln, aber du
untergräbst ja schon Prinzipien der Objektorientierung, also es
ist. Sag ich mal.
Globale Zustände gelten ja auch oft als Antipattern.
Ja, also globale Variablen oder so, weil du halt damit in
Teufels Küche kommst. Irgendwann.
Und genauso kann es dir mit dem Singleton halt auch ergehen und
n riesen unterschied, das muss ich auch einfach mal so sagen,
früher wo ich das verwendet hab oder viel verwendet hab gerade
so am Anfang sag ich mal zweites Semester oder so, wir haben ja
viel am Anfang des Podcast über unsere Studienzeit erzählt, das
ist einfach. Da war mir das egal.
Die Abhängigkeiten, weil weil ich habe keine Tests
geschrieben, ich wollte einfach nur irgendwie diese Aufgaben in
den Programmierkursen lösen und einreichen.
Ja und irgendwie Lösungen schaffen, aber ich habe mir
überhaupt keine Gedanken darüber gemacht, ob das Abhängigkeiten
hat, ob das Testbar und wartbar ist, weil das war sehr
flüchtiger Code. Ja, du hast jede Woche deine
Übungsaufgaben bekommen, du hast es gelöst und danach war das für
dich gegessen das Thema. Und dementsprechend hat man auch
leider sehr schnell die Versuchung gehabt, sich so nicht
gerade Best Practices anzueignen.
Ja, die du dann halt auch wieder loswerden muss und verstehen
muss. Warum ist es denn eigentlich
nicht gut und das kann man ja auch ganz einfach an Beispiel
von Unit Test mal erklären. Ja, ich würde das jetzt mal kurz
ein bisschen technischer machen, nehmen wir noch mal das Beispiel
Logger, es ist ein Anwendungsfall, keine Frage,
aber wenn ich jetzt wirklich testen möchte ob.
Ob das mit meinem Logger klappt, also unter gewissen Umständen.
Ich möchte jetzt wirklich auf Ebene testen, dass ein Log zum
Beispiel geschrieben wird, ja und ich instanziiere den Logger
und mache ein Log und gucke ob das da drin steht, zum Beispiel
ich Speicher mir jetzt wirklich ganz ganz simpel ein ganz
simpler Logger selbst geschrieben, ja und ich Speicher
mir einfach eine Message in der Liste oder so ab ja und gucke
dann ob die Liste jetzt einen Eintrag hat.
So ja hat sie. OK.
Test 1 ist grün. Ja ich wollt jetzt n Error
loggen und der ist da drin so und in Test 2 sag ich log mir
mal ne message ne normale Info hast du es genannt, ist ja auch
so n gängiger Begriff ja als als log Level log mal ne Info ja ist
drin aber die Länge der Liste ist 2 wieso?
Ich habe ja nur ne Info gelockt ja aber da ist ja noch n Error
drin so und dann denkst du ja. OK, warum ist da denn jetzt noch
n Error drin? Und da kommst du halt je nach
Test Framework und je nachdem wie du es aufbaust genau in
diese Teufelsküche, weil du hast einfach die gleiche Instanz von
deinem Logger und hast schon Test laufen lassen.
Ja hast den Error gelockt, der Test war grün und der zweite
Test sagt jetzt. Nee, aber die Länge ist nicht 1
von deinen Blogs, die ist 2. Ja, das.
Droht der Test, du. Kannst ja nicht in jedem in
jedem Test n neues Objekt erstellen oder das irgendwie
resetten, weil du hast es einmal.
Also du hast halt keine Kontrolle mehr da drüber.
Du hast keine Kontrolle mehr, du hast dich quasi selbst ja
ausgeschlossen und jetzt fängst du an zu frickeln, irgendwie
diesen Ausgangszustand wiederherzustellen, wenn du mit
n Singleton arbeitest. Und das ist wirklich n Problem
mit in Sachen Testbarkeit, vor allem der Witz.
Und das ist das das Gemeine. Du schreibst diesen zweiten
Test, lässt den alleine laufen, fährst die Testsuite hoch und
der Test ist grün. Ein Log ist drin.
Info alles perfekt. Ja gut, lass alle Tests laufen
rot ja genau weißt du, du kriegst halt, du hast halt diese
Abhängigkeiten die je nach Ausführung dann.
Echt unterschiedliche Ergebnisse liefern und das ist natürlich in
Sachen testen die absolute Hölle und da ist Single wirklich
gefährlich und deswegen kann ich auch verstehen, dass es
umstritten ist dabei. Ja, auf jeden Fall.
Es ist ja auch, es ist ja auch nicht nur unbedingt, also es
gibt ja auch n andere Beispiele, ne, also es ist es, es macht
manchmal Sinn Single vielleicht zu verwenden, ne oder es ist
durchaus möglich, ich finde immer ich ich finde das immer so
schön, weil das hat einmal jemand gesagt in in in auch n
sehr. Würde ich sagen.
Begnadeter Coder, der Mal gesagt hat, du kannst alles machen,
wenn du weißt, wie es geht, so weißt du und im Endeffekt würde
ich mich auch hinstellen und sagen, OK, wenn du Herr oder
Frau darüber bist, sozusagen ne n Single zu verwenden, dann ist
es kein Problem, wenn du weißt was da los ist.
Wenn du um wenn du verstanden hast was n Single ist, wenn du
wenn wenn du dir dessen bewusst bist, dass du das jetzt wirklich
tust und nicht einfach nur sagst, OK, ich hab gerade Single
kennengelernt, los, los, los, los, ne, dann kannst du das
machen, wenn du es verstanden hast und.
Ne, das ist ja dann auch deine eigene, dein wie sagt man deine
eigene Entscheidungsgewalt darüber?
Ne, aber es gibt auch Beispiele wo es halt absolut gar keinen
Sinn macht zum Beispiel ne also klar, Logger hat mir gesagt OK
macht vielleicht Sinn, ist vielleicht an der Stelle nicht
so gut testbar, was natürlich auch auf jeden Fall n sehr sehr
wichtiger Punkt ist, weil testbarer Code ist natürlich
guter Code, wenn man ihn nicht testen kann, ist natürlich
schlecht, aber angenommen du hast zum Beispiel n Single der
dir sagt OK ich hab jetzt zum Beispiel n User Session.
Ne, also das Singleton nimmt n speichert ne User Session.
Du denkst dir so ja ist doch ne geile sache, du hast doch eh
immer nur einen User der gerade irgendwie aktiv ist und dann
sozusagen du brauchst ja nicht mehr in deiner Session gerade
ne, also angenommen du hast jetzt ne ne API ne und n Rest
Call und jetzt kommt n Call rein und jetzt zum Beispiel hat
irgendwie der erste Call ist zum Beispiel von Alice ne es wird
alles abgearbeitet und Returned und Alice war in dieser Session
gerade drin und dann kommt zum Beispiel n zweiter Call danach.
Zum Beispiel ne vom Bob. So, und jetzt hast du das
funktioniert soweit so gut, solange diese Calls jetzt nicht
zeitgleich kommen, aber wenn die jetzt zum Beispiel zeitgleich
kommen ne und du hast jetzt zum Beispiel Call 1, ne Alice ruft
es auf Alice als oder die ganzen Infos über Alice werden in
dieser Session gespeichert, jetzt kommt kurz danach weil es
fast zeitgleich ist. Kommt ne ne Anfrage vom Bob ne?
Das heißt, jetzt werden die Infos über Bob in der User
Session gespeichert und dann wird aber quasi der Call von
Alice Returnt. Bekommt aber alle Infos von Bob
zurück. So und damit siehst du, dass du
im Endeffekt quasi irgendwas änderst, was du aber in dem
Moment eigentlich gar nicht ändern wolltest.
So, obwohl es sich vielleicht erstmal schön anfühlt, weil du
sagst, ja, da kann ich ja irgendwie global meine ganzen
Daten drin speichern, so ne und das ist aber wieder blöd, ne?
Das wäre jetzt mal das ist. Ja, das ist halt genau der
Punkt. Also du musst halt irgendwie
abstecken können und das macht nachher auch so ein bisschen die
Erfahrung wie wie Wartbar und skalierbar muss meine Software
am Ende sein, welche Änderungen können noch reinkommen, also wie
überschaubar ist es diesen Anwendungsfall einzuschätzen und
jetzt kann man natürlich sagen, ja lieber immer auf die
skalierbare und wartbare Lösung setzen, wir wollen ja gleich
noch eine kleine Alternative an teasern, so ne, weil ganz
ausführlich werden wir es nicht besprechen können in einer
Folge. Aber manchmal gibt es Fälle, wo
es halt so wirklich kleine Softwarelösungen sind, wo du
genau überblicken kannst, wie du meintest.
Wenn man weiß, was man tut, wo das halt dann einfach auch Sinn
macht. Ja, also auf diese Lösung zu
gehen. Bestes Beispiel, Wir hatten ja
vor kurzem mal so n ganz kleines Mini Beispiel Backend
geschrieben und da gab es also ohne jetzt irgendwelche
Frameworks zu verwenden ja also wirklich so so wirklich plain
und. Dann mussten wir uns halt auch
ne Art Mechanismus bauen um ne Art Service bereitzustellen.
Ja und da haben wir dann einfach auch schnell n Singleton
gemacht, so klar, wir konnten dann auch direkt zeigen was das
Problem ist beim Testen. Ja, also das hat man dann auch
direkt gespürt, konnte man lösen, aber man merkt halt immer
wieder wo denn halt die die Nachteile sind und genauso kann
man sagen es gibt ne andere Möglichkeit das umzusetzen ein
ähnliches Verhalten. Und da möchte ich jetzt noch
ganz kurz mit dir darauf eingehen, was so ne Alternative
wäre und ich glaub da ist so n großes Stichwort, was auch
schnell genannt wird, auch gerade von Kritikern gegenüber
den Singleton Peppern is dependency Injection, magst du
das vielleicht das Konzept dahinter mal kurz erklären?
Kann ich machen. Ich würd es glaub ich auch nicht
wirklich sehr vertiefen. Also wir können gerne auch noch
mal ne eigene Folge über die Penency Injection machen, wenn
ja gerne. Das ist nämlich super geiles
Thema. Genau.
Also wenn auch gerade wenn es euch interessiert, liebe zura
Liebe zura, wenn du sagst, ey ist ne coole Sache, würd ich
gern was drüber hören, dann sag uns auf jeden Fall mal Bescheid,
dann können wir das auch, ein Scadulen sozusagen das Thema
kurz gesagt ist die Penency Injection, ich glaub wir hatten
das auch mal in irgendeiner Folge kurz angesprochen, ich bin
mir nicht ganz sicher. Aber da geht es im Endeffekt
darum, dass du beispielsweise, also du nimmst eine eine Instanz
einer Klasse und injizierst sie in eine andere, was im Endeffekt
im Code, sagen wir mal, nichts großartig anderes ist als
beispielsweise ein Parameter, den du übergibst.
Aber wenn du jetzt zum Beispiel sagst, du hast irgendwo in
deiner Main, legst du dir eine Instanz eines Loggers an und
kannst jetzt diese Instanz des Loggers einfach.
Immer weiter sozusagen in deine Software rein injizieren
sozusagen ne die Dependency diese Abhängigkeit rein injecten
sozusagen in deine Software, das heißt du brauchst zum Beispiel
von der Main irgendwann nen Service und dieser Service zum
Beispiel der aufgerufen wird, der braucht n Logger und das
heißt dieser Logger wird dann diesem Service übergeben.
So das heißt kannst dann im Endeffekt rein theoretisch ne
und das ist jetzt wieder das andere.
Du kannst natürlich auch jedem Service ne eigene Instanz
übergeben. Was du dann natürlich nicht
machen solltest. An der Stelle.
Frameworks haben sowas auch zum Beispiel so n bisschen
eingebettet, dass das nicht unbedingt passieren kann.
Ne, dass du sowas halt eben ist es komfortabel gemacht mit
dieser dependence injection, dass du halt eben sagst, OK, ich
möchte jetzt dieses eine Ding was ich mir da angelegt hab
möchte ich jetzt nehmen, so fühlt sich mal n bisschen an wie
n Singleton, dann aber ist es nicht.
Und das ist halt das geile ne, dass große Frameworks.
Genau, weil wir auch gerade Backend hatten.
Ne, also sowas wie Spring Boot oder auch cater und so die Beat
natürlich Packages und Lips sozusagen wo du genau das hast.
Ne du hast das Gefühl von ich habe diese eine Instanz wieso n
Singleton kaufst dir aber nicht die Nachteile ein, weil es halt
über dependency Injection gelöst ist.
Am Ende richtig. Das ist halt geil, genau, aber
nichtsdestotrotz. Kleine Side Note brauchst da
trotzdem ne ganz gute Architektur deiner Software,
weil ansonsten kommst du nämlich auch schnell mal in diese
Möglichkeit, dass du vielleicht dann doch noch mal ne neue
Instanz erstellst. Also es ist, du bist nicht
gewahrt davor neue Instanzen von so einem ne von den Objekten
dann zu erstellen, also auch von Logger.
Ne, du kannst mehrere erstellen, das das muss einem dann
Bewusstsein, aber Fakt ist ist es ist ne Möglichkeit wenn du
weißt wie gesagt wenn du weißt was du tust, dann kannst du es
super machen und dann hast du eben auch gerade weil du die
Testbarkeit angesprochen hast die Möglichkeit zu sagen ich
teste. Es dir jetzt das ganze erstell
mir n neuen Logger und entjekte den sozusagen in meine Funktion,
in meinen Service, was auch immer ne, das heißt du kannst
jetzt. Immer ne saubere Ausgangslage.
Genau, und das ist halt natürlich der der Vorteil und im
Normalfall würde ich so als Daumenregel auch sagen, man kann
Single verwenden, wenn man weiß was es ist und wenn man weiß,
was man tut, sollte man aber definitiv nicht überall und
immer machen und gerne auch auf Dependency Injection auf
ausweichen, was definitiv ne super mega Alternative ist.
Aber auch da muss man wissen, was da passiert, ne?
Ja, die Menge macht das Gift, oder wie sagt man so schön.
Also wenn ich jetzt anfange, überall alles zu injekten, dann
kriege ich halt auch unfassbar viele Abhängigkeiten rein und
komme auch wieder in Teufelsküche am Ende.
Man muss halt immer gucken, ja wie du schon meinst ne gute
Architektur aufbauen, ne das da gibt es ja dann auch, es gibt ja
auch Architektur Pattern und alles ne das sind wir ja heute
nicht, aber. Ich mein nicht ohne Grund
beschäftigen sich sehr viele und schlaue Leute sehr viel mit
solchen Themen. Ne um einfach ne gute Software
am Ende entwickeln zu können und Dependency Injection ist n
cooles Prinzip und hat halt auch seine Tücken am Ende oder muss
man halt auch aufpassen richtig klare klarer Disclaimer hier so.
Genau. Und wir wollten das ja auch
immer n bisschen einordnen, wie stark das zum Beispiel verwendet
wird. Also Single gehört schon das
Pattern zu einem bekannten Design Pattern.
Also man stolpert eigentlich sofort darüber.
Ja, also jetzt mal ohne Scheiß ne, ist doch eigentlich glaub
ich das bekannteste und das erste was man so hört oder weil
es halt auch ich, also ich weiß nicht irgendwie hab ich immer
das Gefühl ist das erste worüber man stolpert, weil es halt so
pro und contra hat, weil es halt auch n gutes Beispiel ist um
direkt zu zeigen es ist nicht die absolute Wahrheit so ne
Pattern zu verwenden, aber man muss immer wissen was vor und
Nachteil ist und wann sie Sinn machen.
Genau. Aber wie gesagt also.
Es es ist es, ich würde sagen, in modernen
Softwarearchitekturen wird es wird das Pattern Single eher
sparsam eingesetzt, aber wie gesagt, nichtsdestotrotz ist es
gut es zu kennen und ich würde es auf jeden Fall auch wenn man
sich jetzt zum Beispiel gesagt hat, ey ich hab das noch nie
programmiert, ich würde vorschlagen, dass man sich
hinsetzt mal und sagt OK ich mach das mal, probier das mal.
Und Versuche zum Beispiel erstmal einmal, dass es
überhaupt funktioniert, ne, also beispielsweise also wirklich zu
verifizieren, dass es dann am Ende auch wirklich nur eine
Instanz gibt, ne und dann vielleicht auch mal zu gucken,
OK, wie krieg ich es hin, dass. Ich so eine richtige Falle mir
aufbauen kann in meinem Code mit so einem Single, weil klar kann
man sich jetzt hinstellen und sagen, ja, wenn es jetzt nicht
so verbreitet ist, gerade in modernen Softwarearchitekturen,
warum soll ich es denn dann verwenden?
Warum soll ich denn dann darüber wissen?
Es hilft halt einfach manchmal um das große Ganze sozusagen
besser zu verstehen und deswegen ist es auf jeden Fall hilfreich,
sich das anzugucken und auch mal auszuprobieren.
Ja. Eigentlich kann man genau das
Loggerbeispiel, wie wir heute erklärt haben.
Mal nachcoden ne, dass du jetzt sagst, OK, ich hab n logger, ich
hab jetzt den das den Bedarf, dass es ihn nur einmal gibt,
weil ich ja immer in den gleichen Speicher sozusagen
loggen möchte. Ich code das wie du meintest
einfach mal n Single und dann Leute schreibt ruhig mal n Test
dazu und probiert das mal aus was denn beim Testen da die
Probleme sind und. Dann sieht man einfach.
Also dann hat man es wirklich mal erlebt.
Weißt du und ich finde, man muss das auch mal erleben, diesen
Pain dabei und dann hat man das glaube ich auch ganz cool
verinnerlicht. Also es ist ne geile Übung, auf
jeden Fall gut, dass du das angesprochen hast.
Aber lass uns mal jetzt zum Abschluss der Folge noch mal
kurz zusammenfassen. Also ich fang noch mal an
Singleton, was ist das Pattern dahinter, also das Singleton
Design Pattern stellt sicher, dass es genau eine Instanz einer
Klasse gibt. Und dass quasi diese Instanz von
überall erreichbar ist. Ja, also ich kann halt nur eine
Instanz erzeugen und sie von überall verwenden.
Das ist erstmal das Petter tipptopp genau, also wir hatten
ja schon gesagt, das ist super für so Dinge, die man vielleicht
zentral steuern möchte, auch mit Bedacht natürlich, wie zum
Beispiel sowas wie n Logger oder was wir jetzt schon paar Mal
genannt haben oder vielleicht auch sowas wie ne bestimmte Art
von Konfiguration. Threadpools oder zum Beispiel
Caches oder sowas in die Richtung ne ist aber kann aber
durchaus wie gesagt gefährlich werden, wenn es halt zu globalen
Zuständen kommt. Und es ist natürlich auch
ratsam, vielleicht gerade wenn es jetzt um die Testbarkeit
geht, muss man mal gucken, da eignen sich.
Solche Singletons nicht so gut hattest du ja auch ein super
Beispiel geben Kino und wenn man da jetzt vielleicht auch mal in
Teufels Küche kommt und sich denkt, verdammt, was habe ich
hier nur gemacht, wieso kann ich das nicht testen, einfach mal
probieren das Ganze mit dem Dependency Injection umzusetzen,
vielleicht flutscht es dann besser.
Ja, und falls ihr da eine eigene Folge zu wollt, dann schreibt
uns gerne, dann machen wir das sehr gerne, weil es wirklich ein
cooles Thema ist. Auch ein sehr lehrreiches Thema
ist und ein cooles Prinzip dahinter.
Ja, ansonsten, liebe Zuhörerinnen, liebe Zuhörer,
stellt sich uns natürlich jetzt die Frage, hast du schon mal mit
dem Singleton Pattern gearbeitet?
Hast du positive oder negative Erfahrungen damit gemacht, wann
hat es dir vielleicht auch mal wirklich geholfen?
Teile gerne deine Erfahrung mit uns, dann können wir sie auch,
wenn du möchtest natürlich gerne mal in einer nächsten Folge mal
vorstellen oder wenn du ergänzende Infos dazu hast, dann
immer raus damit. Wir sind eine große Community
und helfen uns gegenseitig. Und ansonsten schau auch gerne
mal in die Show Notes. Gerade wenn du unsere anderen
Plattformen kennenlernen möchtest.
Du findest auch einen kleinen Spenden Link, falls du uns
unterstützen möchtest. Das würde uns mega freuen.
Bewerte diesen Podcast, wenn Dir die Folge gefallen hat, wie
gesagt Abonnier die Glocke oder da drauf drücken was war wie
weiter empfiehlt gerne den Podcast weiter, das würde uns
mega mega freuen und ansonsten würde ich sagen hören uns alle
beim nächsten Mal wieder und bis dahin habt eine gute Zeit.
Ciao, ciao, deine Kunden bei dies.
Gemeinsam besser.