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.