Also es ist jetzt nur ein Gedankenexperiment, ich mach es so nicht. Ja lass es mir so stehen. Du stehst gerade super da, wenn sie das hören, dann denken sie sich so, och Mensch, der Fabi Coding Buddies, Dein Podcast rund um Softwareentwicklung und aktueller Tech News herzlich Willkommen. Hallöchen, Hallöchen, willkommen zur neuen Folge des Cooningbodys Podcasts.
Schön, dass du wieder eingeschaltet hast, deine Gastgeber. Und wie soll es anders sein, meine Wenigkeit, der Tino und er lächelt mich wie immer an, der fantastische Fabi, Ich möchte dich begrüßen was geht ab Fabi einen wunderschönen guten Tag Tino einen wunderschönen guten Tag auch an dich gerichtet Dankeschön was geht was geht. Was geht so ab? N bisschen kalt so und grad so n bisschen kalt würd ich sagen, aber. Hast du mal, hast du sagt man das beim beim Kalendertag auch?
Hast du mal auf die Uhr geguckt? Nee, also hast du mal in Kalender geguckt, es ist logisch, dass es langsam kalt wird, aber ich find es ist auch so richtig ungemütlich ne also es ist so, das ist ja nicht so kalt schön das ist so kalt, ungemütlich, durchwachsen, ist so nasskalt. Ja, ja, ja, ja, aber das Ding ist so es es kann ja kalt werden, aber trotzdem gibt es manchmal so Tage, wo es einen so
fröstelt. Mhm, weißt du, und manchmal ist es nicht so, also es ist o. K. Und heute ist so n Tag wo es dich fröstelt. Na ja, so n bisschen OK. Na ja, passiert passiert, aber ich denk mal im Laufe der Folge ja wenn du wieder so richtig on fire bist fürs Thema, dann wird das schon wieder gehen, dann wirst du dich fangen, dann schwitze ich wieder wieder so, wenn wieder so hart diskutiert wird. Ist aber echt komisch, weil manchmal schwitze ich bei der. Bei der Aufnahme. Einfach.
Aufregung, schwitzen vom Reden. Das ist die Anspannung, das kennt glaub ich jeder. Du brauchst ja nicht angespannt sein, weil wir haben heute n ziemlich cooles Thema, worüber
wir sprechen können. Aber bevor wir dazu kommen, das ist n Thema, wo vielleicht jetzt der eine oder andere angespannt sein sollte und zwar liebe Zuhörer, liebe Zuhörer, falls du es nicht mitbekommen hast oder noch nicht Teil unseres Turniers bist, es ist jetzt wirklich die höchste oder letzte Eisenbahn, wie sagt man so schön noch mitzumachen, denn nur noch wenige Stunden Minuten am Turnier teilzunehmen, Minuten, Sekunden. Denn wir sind auf der Zigeran
jetzt zum Zeitpunkt der Aufnahme und wir sind mega gespannt, wieviel Einreichungen es am Ende wären. Für unser For connect extreme Turnier. Und ja ich ich bin hypefarbig ich weiß gar nicht was ich noch dazu sagen soll, ich bin absolut Hype, die Phase ging jetzt doch recht schnell rum, die Implementierungsphase, es wurde viel diskutiert auf dem Discord, es gab viel Feedback, viele Leute die gesagt haben sie machen mit, ich bin aber nur Hype, ich hab richtig Bock drauf.
Ja, ich auch. Ich bin auf jeden Fall gespannt, wie es dann wird, wir werden ja dann das Turnier auf Twitch veranstalten, live und in Farbe sozusagen, und mal gucken, mal gucken, ob wir es überhaupt schaffen, an einem Stream durchzuziehen oder ob wir dafür vielleicht sogar mehr brauchen. Ich bin gespannt, kommt drauf an. Genau das werden wir sehen, wenn wir die finalen Einreichungen ausgewertet haben. Wie viele es dann am Ende sind und. Ja, es gibt auf jeden Fall coole
Sachen zu gewinnen. Leute, guckt da mal rein. Auf unserer Website stehen auf jeden Fall die Preise, da kann man mal gucken, was es zu gewinnen gibt, denkt immer dran, gibt auch coole Sachen von unserem Sponsor Jet Brains, also checkt das mal aus, falls ihr es noch nicht gemacht. Habt genau und falls ihr sagt, Nee, das ist jetzt zu knapp, keine Sorge, es werden weitere Turniere folgen, dann macht ihr einfach beim nächsten Mal mit. Und ja genau genug dazu.
Lass uns zum heutigen Thema kommen, wir haben nämlich schon lange keine Design Pattern folge mehr gemacht und deswegen geht es da heute auch direkt weiter. Wir hatten ja als letztes uns das Adapter Pattern angeguckt und sind ja damit so in die. Strukturellen Design Pattern gegangen und da möchte ich heute auch weitermachen und ich hab mal n weiteres ausgewählt, was wir uns heute angucken werden und zwar das decorator Pattern.
Und möchtest du vielleicht einfach mal so n bisschen anteasern, n bisschen langsam rein in die Folge was es mit dem Pattern auf sich hat. Ja, sehr gerne. Tino, sehr gerne. Und zwar ist das decorator Pattern dient ja dafür. Um wie willst du es sagen, halt Objekte. Wie der Name schon ein bisschen
sagt zu dekorieren. Ja, also du kannst zum Beispiel sagen, dass du halt, ich sag mal, wenn du jetzt so n Geschenk hast oder so ne kennst ja ne Weihnachten kommt auch bald, hast n Geschenk und das wird ja meistens irgendwie eingepackt ne und jetzt hast du vielleicht so, dass du dir sagst, ah, dieses Jahr vielleicht mal nicht so viel sich überlegen. Meine Schwester, meine Mutter und meine Oma, die kriegen alle
das gleiche. Ne keine Ahnung, kaufst halt das gleiche, packst es aber anders ein, weil du zum Beispiel sagst ne, aber zum Beispiel Mama, die mag lieber beispielsweise Farbe gelb ja und meine Oma zum Beispiel, die mag lieber die Farbe rot, ne. Die Schwester grünt, was auch immer so und dann nimmst du dementsprechend anderes Geschenkpapier ja und packst dann halt dieses Geschenk ein.
Das Geschenk ist das Gleiche, ist es unterschiedlich eingepackt, aber zum Beispiel weiß ich nicht für die Oma schreibst du noch ne Karte dazu, die du dann sozusagen noch mit dran klebst. Ne an das Geschenk und bei der Mama machst du aber noch ne Schleife dran und bei der Schwester keine Ahnung, ja dann. Kommt nichts mehr dran, weil reicht schon, das wird eh nicht gewertschätzt, weil es ist nicht keiner. Nein, also im Endeffekt erst mal krass, dass du unterschiedliches Geschenkpapier hast.
Ja, also bei mir ist das so. Ich kauf so ne Rolle und da pack ich einfach alle ein, weil es muss ja aufgebraucht werden und dann sehen halt alle Geschenke sozusagen gleich aus, außer natürlich in der im Umfang sag ich mal. Aber vom Geschenkpapier her. Also ich find es erstmal Chapeau, dass du sagst jeder kriegt seine eigene Farbe, das find ich ja richtig toll erstmal. Also es ist jetzt nur n Gedankenexperiment ich mach es so nicht ja lass. Es uns so stehen.
Du stehst Grad super. Da, wenn Sie das hören, dann denken Sie sich so, och Mensch, der. Fabi, ich steh jetzt im Zug. Zwar glaub ich nee auch schon mal Geschenkpapier genau, aber im Endeffekt kann man sich das so vorstellen. Du hast also du hast immer das gleiche Objekt da drin ne, also du hast immer.
Das also du hast das gleiche Geschenk, weil ich ja meint, das sind immer, es sind die gleichen Geschenke für alle 3 Personen, aber man packt sie anders ein und mit anderen Accessoires zum Beispiel ne also du packst da zum Beispiel verschiedene Layer dran, ne Geschenkpapier Schleife oder Karte oder was auch immer ne es kommen unterschiedliche Sachen dran, aber im Kern ist es halt eben das gleiche und so funktioniert es ungefähr halt
eben auch beim decorator Pattern wenn es darum geht, dass du zum Beispiel Objekte erstellst ne und sagst OK. Du kannst die Objekte unterschiedlich dekorieren, mit unterschiedlichen Dingen, aber im Kern ist es das gleiche Objekt, genau, was man da so als Ziel festhalten kann, ist oder die Überlegung dahinter ist, wie kann ich denn Objekte erweitern, wie du so schön meintest? Ja, dass ich jetzt Sie zum Beispiel in Geschenkpapier einpacke, aber sie nicht
modifiziere oder neu schreibe. Das heißt, das Geschenk, wie du ja auch meintest, es ist das gleiche am Ende, das heißt, ich habe mit meinem Geschenkpapier einpackungsmanöver das Geschenk nicht verändert, sondern ich habe nur etwas drumrum gepackt und genau darum geht es halt auch und das ganze versucht man jetzt halt nicht über um jetzt n bisschen in die Objektorientierung zu kommen, nicht mit Vererbung zu lösen.
Also dass ich sage. OK, ich möchte jetzt die Geschenke unterschiedlich einpacken, also hab ich jetzt vererbe ich jetzt von dem Geschenk an sich und hab Geschenk a rotes Papier Geschenk a gelbes Papier weißt du, dass ich mir so einzelne Klassen daraus vererbe? Das ist halt nicht das Ziel, sondern wie du schon meintest es wirklich herum zu packen und Geschenkpapier ist ne super
Analogie weil man das ja auch. Rappen nennt ja, und deswegen wird es manchmal auch halt so allgemein Rapper genannt, das decorator Pattern. Und genau darum soll es heute auch gehen, denn es ist halt auch n sehr mächtiges Pattern, was auch viel eingesetzt wird. Also ich bin mir eigentlich ziemlich sicher, dass jeder, der schon ne Weile codet oder auch relativ schnell am Anfang, wenn man zum Beispiel ja vielleicht mit Python startet oder so, da ist das ja auch so.
Ich sag mal nativ in der Sprache eingebaut. Ja, also du kannst halt dieses decorator Pattern wird dir halt überall begegnen oder halt in Frameworks wie Angular. Ja da hast du sowas auch wenn du jetzt zum Beispiel an Components denkst, wie die deklariert werden, ne, dass das auf meta eben erkannt wird, dass es ne Component ist. Da hast du halt auch Decorators oft auch an so at Symbolen.
Erkennbar ja. Also man muss mal gucken, was unter der Haube ist, aber das ist so n Anzeichen dafür, dass da halt auch unter der Haube so n Pattern verwendet wird und ich find lass uns mal noch n bisschen bei Analogien bleiben, dass man sich das Ganze noch n bisschen besser vorstellen kann, dann würd ich sagen hau ich mal die nächste rein, also das Geschenkpapier fand ich auf jeden Fall cool, das kann man sich gut vorstellen das ganze, ja das fand ich auch richtig gut
ja ja du bist nicht zufrieden mit dir, das seh ich. Das ist. So doof. Aber ich denke, gerade bei der Design Pattern Reihe schulden wir unseren Zuhörerinnen und Zuhörern eine Sache und zwar dass wir ne Analogie mit Essen reden. Also wir werden ja sehr oft sehr oft darauf hingewiesen, dass die Leute immer nach den Folgen Hunger kriegen, weil wir immer so oft über Essen reden und ich finde, das sollten wir jetzt auch nicht einreißen lassen. Und deswegen bringe ich einfach
noch mal so ein. 2. Analogien aus dem Bereich des Essens ja, und zwar stell dir vor, Pizza, Pizza, Pizza ist echt. Ja das war klar, ich weiß auch 3123 Pizza ja Pizza ist halt n super Beispiel dafür, jetzt hast du ja gesagt, wir haben im Prinzip so ne Art Basisklasse, das ist unsere Pizza ja also ne ganz einfache Margarita zum Beispiel. Oder noch einfacher, ohne Käse, einfach nur so mit Tomatensoße drauf.
Ne, du hast den Teig, du hast ne gewisse Form und Tomatensoße drauf, das ist so deine Basisklasse, da geht der Daumen hoch, ganz genau fabi das ist super ne super Basis für ne Pizza und ja jetzt möchte ich aber verschiedene Varianten machen, aber ich möchte ja nicht sagen in meinem Code oder sagen wir mal so von der Vorstellungsweise, dass ich jetzt Objekt. Hawaii Pizza um nur mal kurz n
paar Leute zu triggern. Ja tono keine Ahnung was es alles gibt, so ja dann will ich ja nicht sagen, das ist also ich sag ja nicht ja nee das ist ne Hawaii Pizza und das ist ne Thunfischpizza im Sinne von das sind 2 komplett unterschiedliche Sachen weil unter die Basis dahinter ist ja die gleiche Pizza ne also wie stell ich diese Pizza her ich es sind ja keine unterschiedlichen Herstellungsprozesse, dass ich nicht die gleiche Basis hab, sondern.
Ich belege sie ne, also ich veränder nicht meine ganz klassische Pizza, die liegt jetzt vor mir. Ja keine Ahnung was ist so n Standard 28 Zentimeter Durchwasser keine Ahnung super und dann fang ich halt an sie zu belegen nachdem wie ich sie haben möchte aber ich veränder ja nicht meine Grundpizza und genau das ist das decorator
Prinzip dahinter, das heißt? Ich kann während der Herstellung, und das ist jetzt n ganz wichtiger Punkt bei dem Pattern, ich kann während der Herstellung ja entscheiden, wie ich Sie haben möchte, indem ich sie dekoriere. Mhm. Ja, mit Geschenken. Also ich muss ja nicht quasi während ich den Teig ausrolle, ist ja noch nicht wichtig, was für ne Pizza das wird, sozusagen, es ist ja die gleiche Basis, das heißt ja keine Ahnung, ich mach den Schinken drauf, ananaskäse drüber.
Ich find das Beispiel einfach super und dann hab ich ne Hawaii Pizza hergestellt. Aber wie gesagt das ist die Basispizza dekoriert mit Schinken, mit Ananas und mit Käse mit Geschenkpapier. Also ich erweiter das und in Geschenkpapier eingepackt am Ende gelbes klar bei Pizza und
da das ist halt. Ich find daran kann man das gut erkennen, weil jetzt nehm ich die nächste Basispizza und mach statt den Schinken mach ich dann Thunfisch, Zwiebeln, keine Ahnung was da drauf kommt ne und wieder Käse also käsebuster Käse kannst du fast zur Basispizza erzählen. Ja und und so kann man sich das ganz gut vorstellen ne dass ich sage ich habe ein Objekt was ich nicht veränder, ich erweiter es nur ich dekoriere es nur um quasi.
Zur Laufzeit in der Herstellung während ich es tue, quasi nicht im Vorfeld entscheiden kann. Wie soll sie aussehen, ne, weil ich ich sag ja auch nicht ich hab 5 mal die Pizza und 5 mal die Pizza jetzt mach ich den lan auf und jetzt nimmst du die oder nicht die sind in Stein gemeißelt sozusagen ne also ich habe jetzt feste Objekte. Hawaii Pizza und Thunfisch, Pizza und jetzt kommen die Leute gut, ich hab noch 3 Hawaii, nimm
davon ein oder nicht. Klar man wir gehen jetzt mal davon aus, dass du sie frisch machst. Ja, sondern du bestellst und kannst dann während der Herstellung entscheiden wie sie aussehen soll und genau dafür ist dieses Pattern halt. Super. Ja, und du hattest es ja eben schon n bisschen gesagt, dass man ja im Endeffekt auf der Karte sagen kann, OK, ich möchte
also. Du siehst die Karte und sagst so ich möchte ne Hawaii Pizza, aber es wär irgendwie ganz nett wenn keine Ahnung ich ich möchte nicht den Schinken drauf haben, ich mag total Ananas auf der Pizza aber ich möchte gerne keinen Schinken drauf haben wär das auch möglich, dann kannst du das ja auch theoretisch machen aber und das ist ja genau der Punkt, du hast jetzt zum Beispiel ne Hawaii Pizza aber du hast jetzt zum Beispiel nicht so was wie ne Pizza.
Grundpizza, Ananas, grundpizza, Ananas, Schinken, Grundpizza,
Ananas, Schinken, Käse. Weißt du also du hast jetzt nicht sozusagen da diese ganzen Permutationen auf der Karte, die du irgendwie vielleicht sag ich jetzt mal, herstellen könntest, weil das wäre jetzt zum Beispiel wieder so ne Art und Weise, das Ganze in Vererbungen oder Klassen zu packen, dass du sozusagen so Klassenexplosionen am Ende hast und sagst, du machst von jeder Eventualität legst du dir halt eben irgendwie im Vorfeld schon mal ne Klasse an, damit du auf alles
vorbereitet bist. Ne, und dann hast du natürlich irgendwann einfach nur noch riesen Wirrwarr und das ist halt so n bisschen der natürlich der Vorteil, wenn du sagst, du kannst es halt dekorieren wie du möchtest, ne aber Tino eine Frage warum dekorierst du die Pizza und bildest sie nicht? Also ja, man kann natürlich dabei also auch direkt an das
Factory Pattern denken. Ja, also dass du sagst in der Herstellung ne, ich erstelle unterschiedliche Pizza Objekte so, das ist ja haben wir auch drüber gesprochen, kann auch n Anwendungsfall sein, wir haben auch zu dem Zeitpunkt. Burger und Pizza vielleicht auch.
Ich weiß es gar nicht mehr. Es ging auf jeden Fall auch um Essen genannt, warum dann Factory Pattern auch in Ordnung ist oder ein Anwendungsfall ist als Analogie und das ist halt genau die Frage, die man sich da stellen muss, wie flexibel muss ich zur Laufzeit sein, das ist eigentlich so der der Kerngedanke ne und möchte ich nicht meine Basis verändern.
Ja. Das sind, das sind so die unterschiedliche, also das eine ist ich modifizier, mein mein Objekt und das andere ist auch so n bisschen ich modifizier mein verhalten, wir bringen nachher ich hab noch n mir noch n anderes Beispiel überlegt was so n bisschen technischer ist, wo man das denn noch n bisschen genauer erkennen kann, da wo wo man denn quasi sagen kann hier ist so die Grenze wo zum Beispiel n Factorypad dann gar nicht mehr.
Sinnvoll ist, sondern es eher darum geht, n anderes Verhalten aufzurufen und man da eher zum Beispiel sowas wie ein decorator Pattern verwenden sollte. Ich find. Es auf jeden Fall lustig, dass du auf Factory pattern kommst,
weil das stimmt. Ich hab gerade tatsächlich an Bilder Pattern gedacht, weil rein theoretisch könntest du ja auch dich hinstellen und sagen, ich nehm zum Beispiel n Bilder pattern um eventuell so ne Pizza aufzubauen, ne ist aber sind aber wie gesagt, man kann ja, das ist ja im Endeffekt genau der Punkt, man kann für. Man kann immer unterschiedliche Pattern theoretisch für das Gleiche verwenden.
Die Frage ist aber dann am Ende natürlich welches passt dazu ne und das hatten wir auch immer schon in den Folgen bisher gesagt, es ist meistens so, dass du auf jeden Fall in der Lage bist verschiedene Pattern zu nutzen für das gleiche Problem, aber man muss halt immer n bisschen gucken, OK, welches passt denn jetzt am besten? Manchmal passen aber auch mehrere, das ist n bisschen abwägungssache, ne? Lass uns das noch mal n bisschen klarer machen bei der Pizza.
Nicht, dass da jetzt Verwirrung aufkommt, ne, also wenn ich jetzt rein über die Herstellung der Pizza spreche, so wie ich es gerade getan hab, gut kann man sagen kann man argumentieren OK da ist ne Factory oder n Bilder also n herstellungspattern ja n Erschaffungspattern sinnvoller OK gehen wir aber mal wirklich aufs Verhalten, zum Beispiel was kostet mich die Pizza am Ende? Ich möchte jetzt berechnen. Ja, ich glaube, das kennt jeder.
Zum Beispiel, wenn man Pizza bestellt und man sagt, ich möchte weitere Zutaten da drauf haben, dann sind da ja so Preise angegeben, ne, also keine Ahnung was hatte ich hawaii, ich will jetzt nur Ananas auf ne normale Schinkenpizza legen lassen, das Kost mich oh Mann ich muss mir irgendwas ausdenken, keine Ahnung ob das realistisch ist 1 50 oder so extra ne für dich Pizza für dich aufpasst würdest du nehmen ist n fairer Deal super ist n fairer Deal. So, und wenn man sich sowas
vorstellt, da komm ich halt dann wirklich in das decorator pattern, dass ich sage, ja, berechne mir doch mal was die Pizza kostet ne basispizza ja kostet immer das Gleiche, das ist dein Objekt und das willst du auch nicht verändern, du willst ja jetzt nicht zum Beispiel mit dem Factory Pattern sagen na ja gut, ich erzeuge mir jetzt unterschiedliche, sag schon pizzen, ja und? Den Preis muss ich immer neu setzen, weil ich muss dann gucken, was drauf ist.
Ich errechne mir das und kann dann sagen, was die Pizza kostet. So, das kann ich machen, wenn ich ne klein. Also wenn ich ne kleine Variante hab ne wie wir es damals besprochen haben, du hast ne Karte, da sind 5 Pizzen drauf, das sind jetzt 5 verschiedene Objekte sozusagen und anhand mit meiner Factory kann ich entscheiden welche zurückkommt wenn ich mir jetzt aber
vorstelle. Jetzt möchte aber jemand Zusatz zusätzliche Zutaten da drauf haben, dann fang ich ja nicht an in der Factory neue Objekte zu erzeugen. Zu sagen Oh warte mal der der Kunde gestern ne der der war richtig crazy, der wollte auf seine Hawaii Pizza einfach weiß ich nicht ja Zwiebeln Sardinen das ist Crazy Sardinen da drauf haben ja und dann warum soll ich jetzt ne Pizza erschaffen ne Hawaii Sardinien was keine Ahnung OK der war schlecht
sorry. Und hab halt quasi n komplett neues Objekt dafür, sondern da bietet sich dann ja wirklich zu an zu sagen, nee, ich habe meine Hawaii Pizza und dieser Kunde kriegt jetzt halt da sardin drauf und dann berechnen wir also zur Laufzeit n anderes Verhalten und n neuen Preis und da kommst du halt dann ganz schnell in die Bereiche wo denn ein dekorator Pattern einfach besser ist. Ja beziehungsweise wie du auch meintest, man kann es mit verschiedenen Sachen lösen und das eine.
Verbietet nicht das andere. Ich kann ja ne Factory haben und darauf aber trotzdem noch aufbauen. Richtig. Ich hoffe, das hat es mit dem Preis noch mal n bisschen klar gemacht.
Ja, ist so. Also ich find es auf jeden Fall fand es auf jeden Fall sehr gut erklärt, auch wenn jetzt zum Beispiel wenn man sich jetzt hinstellen würde und sagen würde, um das jetzt auch noch mal abzugrenzen, du hast n decorator und du hast n Builder, es sind halt erstmals sag ich jetzt mal Design pattern aus verschiedenen.
Kategorien ist eines n Erzeugermuster, das andere ist n strukturmuster ne und also sein Decorator ist n strukturmuster und der Bilder ist n erzeugermuster und genau beim Decorator ist es ja so, dass man sagt wie wir ja schon jetzt paar mal gesagt hatten, ich möchte das Verhalten eines Objektes zur Laufzeit erweitern, ne das heißt ich hab jetzt n Objekt und möchte da noch was da hinzufügen das heißt du kannst wie gesagt zur Laufzeit einfach dem Objekt noch ein bisschen mehr
dazugeben. Bei einem Builder ist es so, dass du eigentlich nichts anderes möchtest, als relativ bequem ein komplexes Objekt kontrolliert zu. Also erstellen sozusagen ne und da ist es ja so, dass du wirklich ein Objekt hast, ne was du irgendwie erstellst auf verschiedene Art und weisen. Es wird aber n relativ komplexes Objekt sein, bei einem Decorator ist es halt so, dass du eigentlich sagen wir mal n relativ simples Objekt hast.
Was du aber immer so je nach Gusto halt eben erweitern kannst, ne. Genau.
Um das noch mal abzugrenzen, aber ich find das halt relativ spannend, weil ich kann mir durchaus vorstellen, bei mir ist es zum Beispiel früher mal so gewesen, dass ich mir dachte, so OK, jetzt kommt das Pattern. Aha OK, ja versteh ich, jetzt kommt das pattern aha ja OK versteh ich jetzt kommt das pattern Moment warum kann man eigentlich für alles das Gleiche nehmen weil ne das ist finde ich das macht die Sache weil du es ist ja durchaus möglich mit der gleichen Analogie ähnliche
Pattern zu erklären. Aber diese kleinen Feinheiten, die dahinter stecken, und das hat mich zum Beispiel früher manchmal etwas verwirrt, weißt du? Ja, ja, absolut verständlich. Ich find deswegen ist auch wichtig, immer mit vielen Beispielen und Analogien zu arbeiten und deswegen landen wir auch immer beim Essen, weil da kann glaub ich jeder mitreden, weil jeder liebt Pizza und wenn nicht dann krass wow. Aber lass uns noch mal ein technischeres Beispiel technischeres Beispiel auch das
Technischere was ist? So du meintest, du hast da noch einen Zauber raus. Genau. Und zwar lass uns mal an so ne nottifire klasse denken, ne. Also wir haben jetzt irgendwie eine Software entwickelt und müssen so Benachrichtigungen rausschicken und haben so nen klassischen Nottifire eingebaut, der e Mails versendet so damit das ist unsere Basis. Ja also damit ging es los.
Und haben uns nichts weiter dabei gedacht, nicht irgendwie an Pattern gedacht, weil es gibt halt nur diesen ein Notifire und auch nur die Funktionalität oder das Verhalten, dass E Mails rausgeschickt werden. Und auf einmal heißt es dann, na ja, aber in dem und dem Team oder in der und der Anwendungssache. Wär es halt nicht schlecht, wenn wir zum Beispiel wir nutzen, sag ich mal als Slack auf Arbeit. Ja und wir möchten auch, dass in einen gewissen Channel
geschrieben wird. Ja so n klassisches Beispiel, keine Ahnung, unsere Pipeline hat n Fehler geworfen im CIC Detail ist irgendwas nicht am Ende integriert worden oder nicht deployed worden, das wollen wir als Benachrichtigung in so einem Team Channel haben. Als. Beispiel ne. Oder was ist noch klassisch SMS?
Ja, ich möchte ne Benachrichtigung aufs Handy haben, von mir aus weiß nicht, dass das SMS für dich klassisch ist, aber na ich find das also Steinzeit, also sagen wir mal du kriegst irgendwie so n das kennt doch jeder, dass du so n Code aufs Handy geschickt bekommst oder so OK touché ja ist OK, es geht auf alles gut, pass auf, du kriegst n Brief nach Hause so
jetzt kannst du Steinzeit sagen. Ich schreib dir n Brief mit der Benachrichtigung auf jeden Fall, worauf ich hinaus möchte ist, dass man ja dann in diese subklassen Hölle kommt, ne wie du so schön meintest, weil du fängst ja jetzt nicht an und zu sagen OK warte mal, warte mal. Wir haben jetzt so verschiedene Nortifier ja OK warte mal ne das ist nicht schlecht, da machen wir jetzt, da machen wir, da machen wir Factory, ich greif noch mal ich nehm das noch mal ne so dann haben wir ne.
E Mail notifire Slack, notifire, Essen, Essen, Notifire, Brief, Notifire und so kannst du ja anfangen. Aber was ist, wenn jetzt die Leute sagen, na ja, warte mal, warte mal, warte mal, aktuell wär es nicht schlecht wenn wir zu der E Mail noch n Slack notifire hätten, also da die Benachrichtigung kriegen das würden wir gerne genau. Die sagen jetzt einfach, wir möchten das gerne aktivieren. Ja OK, ich baue meine Factory in e mail slack notifire ein.
Ja nee, machen wir noch, machen wir noch mal SMS auch noch dazu, weil SMS finden wir toll gut e Mail Slack SMS notifire implementiert so und das da sieht man ja schon, wo soll das hinführen? Du willst ja nicht für jede Kombination jetzt ne Instanz erzeugen mit den gewissen Eigenschaften gerade wenn du zum Beispiel sagst ey ich möchte bitte notifications an und ausschalten.
Können. Ja, du willst ja nicht auf alle Individualitäten vorbereitet sein und da nutzt man dann einfach n Decorator und sagt OK, das Standardverhalten ist e Mail, du willst SMS bau ich dir drum rum dein Standard notifie ist der gleiche, nur zusätzlich zu der Funktionalität versende ich noch ne SMS oder ne Nachricht auf dem Slack Channel und da finde ich das ist n richtig klassischer Anwendungsfall. Der wo das Decoratorpad dann einfach so richtig seine Stärken ausspielen kann.
Definitiv. Das ist ja auch das, was ich vorhin so so meinte, dass man ja theoretisch, wenn du diesen Decorator zum Beispiel nicht nutzen möchtest, aber. Das irgendwie anders lösen möchtest, kommst du relativ schnell in so ne klassenexplosion, dass du halt irgendwie alle Kombinationen permutationen.
Wie auch immer von den entsprechenden Möglichkeiten die du hast, irgendwie kombinierst ne und wenn du sagst, OK du hast 2, dann hast du halt vielleicht nicht so viele Möglichkeiten, aber je mehr es halt werden, desto mehr Klassen würdest du haben und ich find das ist auch wieder mal n gutes Beispiel zu
sagen, du baust etwas. Was zum Beispiel eventuell in Zukunft ne, also das ist halt immer genau so n bisschen das was man so auch bei softwarearchitektur sich dann überlegen kann, weil klar wir hatten über so Dinge gesprochen wie jagny ne you ain't Gonna need it so nach dem Motto OK, ist doch jetzt erstmal egal, du brauchst es gerade nicht und das ist so n Trade auf zwischen dem was. Aber wahrscheinlich in Zukunft passiert. Weißt du, dass du halt gucken musst?
OK, klar, du brauchst es nicht, also Bau jetzt zum Beispiel noch keinen Slack notifire, wenn du ihn noch nicht brauchst. Das ist ja logisch, aber setz doch deine deine Software schon mal so auf, dass angenommen sowas würde kommen, du es. Relativ einfach erweitern kannst, ohne dass es hinterher so n Mess wird. Weißt du, dass du hinterher sagst, so, oh mein Gott, wo sind wir hier gelandet?
Ne packst noch 5 notifier, die dann in den nächsten halben Jahr dazu kommen mit dran und denkst dir dann auf einmal oh Gott, wir haben aber hier völligen Scheiß gemacht ne das ist so finde ich dieser kleine Unterschied zwischen man muss gucken wie man seine Software baut. Aber nicht das implementieren,
was man noch nicht braucht. Ne und das finde ich kann man relativ gut auch mit solchen Patterns dann teilweise gewährleisten, weil du halt sagen kannst, OK ich bau das so auf und kann dann zukunftssicher meine Software sozusagen erweitern, wenn es denn sein muss, aber muss erstmal noch nicht das implementieren was ich noch nicht brauche, das ist eigentlich immer ganz cool und der Vorteil auch von solchen Patterns dann zum Beispiel. Genau, weil das decorator
Pattern ja auch wirklich dafür gut geeignet ist, weil du halt deine basisimplementierung, deine Basisklasse ja nicht modifizieren musst. Also du baust wirklich drumherum muss man natürlich auch gucken, dass das nicht ausufert, sag ich mal. Aber dann, da sieht man ja auch, wieso Pattern denn einfach wirklich sehr viel Struktur reinbringen, also in den Code jetzt. Genau. Also es ist im Endeffekt auf jeden Fall NN super pattern um, ich sag mal dieses.
Schöne diesen schönen Satz. Man ist offen für Erweiterung ne, aber geschlossen für Veränderungen so. Ja, ja genau das Filter genau, aber dann haben wir jetzt quasi so n zum Beispiel das Beispiel diesen Basisnottifire ne und wie du meintest You aint Gonna need it. Das war einfach zu dem Zeitpunkt genau das was gebraucht wurde und deswegen gibt es halt nur das. Jetzt hatte ich ja gesagt OKSMS Slag alles Mögliche. Wie funktioniert denn das technisch jetzt da n decorator
Pattern einzubauen? Genau, also NN decorator Pattern, wenn man sich das so grob überlegt, da brauchst du ungefähr so 4 Klassen, ne also oder was heißt Klassen?
Also du brauchst 4 Konstrukte und zwar brauchst du einmal die Komponente selber ne, also nennen wir es mal Komponente ne zum Beispiel diesen Notifire. Das ist aber jetzt keine Klasse, das ist n Interface mehr oder weniger ne was n Interface ist hatten wir glaub ich auch schon 1 der ersten Pattern folgen erklärt und in diesem Interface steht eigentlich nur die Beschreibung drin was so n notifier können muss, beispielsweise ne also was was was soll der können ne zum
Beispiel hat der dann die die Funktion notifier und zum Beispiel noch sowas wie was weiß ich ne Get Name hat n Namen kannst du n Namen holen ne also dass du halt im Endeffekt nur
beschreibst. Wie n klassisches Interface was kann denn theoretisch dieser also so ein Notifire, ne, also jedes Objekt was ein Notifire ist, kann halt eben dieses Notifire eben machen und wenn du dann sagst, OK du hast dann aber von diesem, von dieser Komponente, diesen Notifire, hast du dann logischerweise auch wieder eine konkrete Implementierung. In dem Fall dann zum Beispiel Simple Notifier, ne beispielsweise simple Notifier könnte jetzt einfach nur der E Mail notifier sein, ne, so
kannst es jetzt erstmal nennen wie du möchtest, kannst du auch sagen, OK es ist der e Mail notifier, weil du auf jeden Fall sagst e Mail wird immer versendet, egal was ist ne so also nennen wir es mal abstrakterweise etwas einfach nur simple Notifier der auf jeden Fall ne e Mail rausschickt so ne und wenn du dann implementierst also die Funktionalität notifier. Im simple Notifire in der
konkreten Komponente sozusagen. Dann wird auf jeden Fall ne e Mail versendet und wenn du sagst, gib mir mal den Namen, dann heißt es OK, der Name ist jetzt beispielsweise e Mail notifire oder simple notifire wie du möchtest ne sagen wir mal jetzt, der simple Notifire gibt dann halt die e Mail notifire als Name raushält, damit man noch mal so n bisschen den kleinen Unterschied vielleicht so sehen kann ne und dann kannst du halt eben noch diesen Dekorierer.
Erstellen und der Dekorierer ist im Endeffekt sagen wir mal ne abstrakte Klasse die den das Interface wie hatten wir es genannt Notifire also diese Komponente implementiert. Ne, das heißt du hast sozusagen dann ein sagen wir mal notifire decorator ne der dann sozusagen den Notifire implementiert. Soweit so gut. Ja, bin bei dir sehr gut.
Und dann hast du aber in diesem Decorator, in dieser abstrakten Klasse hast du ein Objekt hängen, was im Endeffekt der Notifire ist, ne, also dieser dieses Interface notifire so. Und jetzt kannst du halt, und das ist jetzt so n bisschen das, was dann oben drauf kommt, einen konkreten Dekorierer ne.
Also wir hatten ja ne Komponente, ne konkrete Komponente und jetzt haben wir n dekorierer und einen konkreten Dekorierer sozusagen Implementierung davon genau also wieder ne Implementierung. Vom Decorator sozusagen, von der abstrakten Klasse Decorator ne, also von dem Notifire Decorator.
So, und das heißt, du kannst dann zum Beispiel deine E Mail noch dekorieren, wie wir es ja gesagt hatten, wir werden Geschenk zum Beispiel kannst du jetzt anstatt gelbes Geschenkpapier nimmst du jetzt aber zum Beispiel diesen die SMS dazu oder anstatt rotes Geschenkpapier nimmst du dann vielleicht aber beispielsweise die Slack Notification dazu und dann kannst du halt sagen, OK pass auf, du hast halt in deinem konkreten Dekorierer ne, also in deinem.
Sagen wir mal Slag decorate, also Slag notifier decorator
nenn ich das jetzt mal. Hast du dann die Möglichkeit zu sagen, OK, ich muss ja ebenfalls die Funktionen noti, also Notifier und get Name implementieren muss ich ja auch machen, nur dass dann im Endeffekt, dass du dann sagen kannst, ich kann aber von meiner von meinem simple Notifier die notifier Funktion aufrufen, ne. Und kann dazu aber noch ne andere Notifier aufrufen, also sozusagen in eine eigene Implementierung. Also wird einmal ne e Mail
rausgesendet, weil du sozusagen von deiner ursprünglichen, von deinem simple Notifier sozusagen diesen notifier aufrufst und zusätzlich, das ist die E Mail und zusätzlich eben noch dann deine Slacknachricht verschickst ne und genauso wenn du dann sagst, gib mir mal den Namen von diesem Notifier, dann steht da zum Beispiel simple Notifier und.
Slack, Not die Fire oder so, dann weißt du auf jeden Fall OK, diese beiden Sachen werden hier also quasi gemacht, so wenn du es jetzt in get Name verpackst ne. So, ja, ja, genau das ist ja auch so n bisschen, dass der Trick dabei, warum das so schön funktioniert.
Weil man kann sich das ja wirklich, wieso n. Stapel am Ende vorstellen ne, also ich hab so meine basisimplementierung ich Stapel halt immer weitere Funktionalitäten drauf, das heißt die eigentliche Funktionalität ist die gleiche, ich packe einfach nur noch mehr drauf und ändere aber nicht die eigentliche Implementierung, da zum Beispiel das Beispiel mit dem mit dem Preis für die Pizza.
Ja, also wenn ich jetzt halt die dieses decorator Pattern nutze und mir quasi auch immer wieder ne Instanz zurückgebe von dem wie es aktuell aussieht ne. Also ich hab die Basisinstanz, die hab ich OK, dann sag ich also gehen wir mal davon aus wir haben ne Margarita, bauen wir das noch mal komplett auf das Beispiel so da ist nichts drauf, dann sag ich ja jetzt hab ich n decorator Salami und ich Schinken gerade mal vorhin Schinken. So, dann nehm ich jetzt ne
Implementierung von meinem Decorator und sag zum Beispiel ist der Schinken decorator. Das ist n klassischer Name für sowas. Ja so und da geb ich meine Basispizza rein, das heißt der kennt jetzt meine Basispizza ne und die hat zum Beispiel sowas wie Get Cost ne und da steht keine Ahnung. 5€ sagen wir mal drin ja genau dann kann ich sagen ich implementiere da ich ja das gleiche Interface implementieren muss get cost. Sag ich. OK, ich habe ja meine Basispizza quasi als Eingabe bekommen.
Ja. Dann ruf ich davon einfach get cost auf. Das sind 5€ und Addiere jetzt was 1 50 dazu für den Schinken und das ist meine Get Cost für Schinken n fairer Preis denk ich ja so also sag ich dir einfach ich nehm einfach wirklich die Implementierung, ich rühr die nicht an die Pizza, die Standardpizza kostet weiterhin 5,00€. Ich bau nur drumherum, dass ich jetzt Schinken drauf lege und sage plus 1 50 genau und gebe
das wieder zurück. Und das ist immer noch eine Pizza. Ne, das ist halt das richtige. Immer genau, genau, genau. Es ist immer noch die Pizza, nur dass ich jetzt noch die weiter dekoriert hab, das ist n schönes Wort, passt einfach auch bei Pizza ne man sagt ja ne Pizza dekorieren, das kennt man ja könnten sie meine Pizza? Vielleicht aber auch noch mit ein bisschen Tomaten dekorieren. Guter Punkt, dann legen wir jetzt noch Tomaten.
Auch jetzt haben wir die Pizza, wo schon Schinken drauf ist. Und jetzt ruf ich den Tomatendekorierer nehm ich jetzt und erzeug ne Instanz davon, gebe jetzt aber nicht die Basispizza rein, sondern schon da wo der Schinken drauf ist ne und und so weiter und ich Stapel das immer weiter, die Get Cost gibt mir mittlerweile 650 zurück wenn ich die Aufrufe und ich sage plus 1€ so. Und geb das Objekt wieder
zurück. Und wenn jetzt jemand davon die Get Cost aufruft, dann steht da halt was sind das denn 57 drin? Genau und genau das ist der Punkt, ich kann es halt immer weiter stapeln und immer mehr Funktionalität hinzupacken genau also trotzdem ist es am Ende meine Pizza.
Richtig also das wenn man jetzt sagt, zum Beispiel du hast ne diese Basispizza ne und wie du meintest, du nimmst jetzt zum Beispiel den Schinkendekorierer und gibst daraus natürlich logischerweise wieder ne Pizza zurück aus dieser.
Aus der decorator Funktion der des Schinken Decorators und du machst danach diese Tomate, dann ist es ja nicht so, als würde die Pizza sagen, OK, jetzt nehmen wir ne die Schinken wieder runter und machen nur die Tomate drauf, sondern wie du meintest es wird gestapelt ne und das ist halt das das interessante dabei, dass du halt eben nicht sagst OK jetzt das anstatt das sondern das und das so das heißt wenn du jetzt zum Beispiel sagen würdest du machst aber Schinken, decorator
Schinken, Decorator, Schinken, Decorator. Tomatendecorator dann hast du natürlich dreimal Schinken drauf und einmal Tomate. So ne. Ja. Genau. Ja, gibt es auch. Manche Leute finden sowas cool, so Doppel, Doppel, Schinken auf der Pizza oder so, keine Ahnung, genau das mal so als exaktes Beispiel Mhm, also im Prinzip was passiert unter der Haube die Methoden die ich ergänze in meiner Implementierung durch meinen neuen Decorator ne da.
Die rufen am Endeffekt oder leiten am Endeffekt zu den inneren Objekt weiter verwend die Funktionalität und Kapsel noch draußen, wie du meintest, als wieso n Geschenkpapier noch ne extra Logik drumherum und das ist halt ne wunderbare Sache die sich echt in vielen Fällen gut einsetzen lässt und vor allem gerade wenn es darum geht das zur Laufzeit ja zu entscheiden auch sehr wie soll ich sagen. Straight und Linus also es ist codetechnisch halt dann auch einfach schön gelöst.
Es ist erweiterbar, es ist skalierbar und das sind ja alles Faktoren, die man absolut möchte in der Softwareentwicklung und deswegen würde ich gern noch mal auf so n paar Prinzipien eingehen, die hinter diesen Pattern stecken. Was du schon gesagt hast, war ja dieses Open Close principle ne, also offen gegenüber Erweiterungen oder oder offen für Erweiterung und geschlossen für Veränderung.
Ja weil ich halt wie gesagt die Basispizza nicht modifiziere, es ist die Basispizza am Ende, dann hatten wir ja gesagt warum nicht Factory in dem Fall weil mit Factory kann ich ja auch unterschiedliche Pizzen erzeugen ja ist richtig. Aber an dem Punkt sagt man Komposition über Vererbung, gerade weil es zur Laufzeit, also zur Runtime dann einfach
passiert. Ne, also ich möchte lieber Objekte kombinieren als sie zu vererben, um dann so in diese subklassen Explosion in die Subklassenhölle zu kommen. Genau. Das sind so 2 Prinzipien, die da auf jeden Fall dahinter stecken. Und ein drittes Fabi hast du noch 11 was hinter dem Decorator an sich noch steckt? Single Responsibility zum Beispiel. Das heißt, jede nenn, das Schicht, jede Dekorierungsschicht macht halt nur eine Sache, ne. Also du hast dann zum. Beispiel, Das stimmt ja.
Wenn du halt sagst, du hast, du willst halt Schinken drauflegen, ne mit dem Schinken decorator, dann passiert halt auch eben nur das ne. Also du gibst halt eben die entsprechende Verantwortlichkeit zu den entsprechenden Decoratoren halt eben weiter, was natürlich wie wir auch wissen, mittlerweile sehr sehr gut ist.
Für zum Beispiel auch die Testbarkeit eines einer Software, beispielsweise ne. Ja, hilft also mit Single Responsibility meinst du ja im Prinzip jetzt zum Beispiel n Schinken Decorator wird auch nur Schinken drauflegen, genau er ist nur dafür verantwortlich Schinken auf die Pizza zu legen. Genau, also du hast keinen Hawaii Pizza decorator, das hast du nicht, sondern wenn du eine Hawaii Pizza haben kannst, dann kannst du vielleicht so ne Art Funktion machen make Hawaii.
Ne wo dann zum Beispiel der Schinken Decorator aufgerufen wird und wo dann zum Beispiel der ne Ananas Decorator aufgerufen wird. OK, aber es gibt keinen Hawaii decorator so. Weil dann könntest du wieder. Ja, schon wieder eher den die Factory am Ende. Genau das würde ich sagen, ich bestell ne Hawaii.
Richtig, das wäre die Factory und dann hättest du ja schon vielleicht schon wieder so eher so ne Art Vererbung, dass du sagst, du hast ne Basispizza und du hast zum Beispiel ne Hawaii Pizza und die Hawaii Pizza quasi ist ja hat ja als Basisklasse die logischerweise die Basispizza ne bedeutet, aber dann wiederum wie du ja schon meintest, dass es am Ende ja sehr fest und starr ist, weil du musst diese Klassen alle schon kennen, bevor du überhaupt in die Laufzeit sozusagen kommst, ne? Keiner.
Ja, das ist eigentlich auch der große Vorteil, weswegen wir das Pattern auch ausgewählt haben, dass du das Verhalten zur Laufzeit anpassen kannst. Das ist der große Benefit dahinter das der riesen Pluspunkt Ne und dass deine Klassenstruktur nicht explodiert, das wären jetzt so mal 2 Vorteile die mir da sofort einfallen. Genau, ich meine Nachteile. Da weißt du ja relativ schnell, was das Ganze mit sich bringt. Du musst halt natürlich, du
musst halt gucken. OK, du hast logischerweise irgendwie wieder ne Art Overhead, ne, weil du musst. Wie gesagt, das besteht ja, wenn du es ganz knapp machst, besteht es ja aus, ich sag mal 4 Komponenten die du ja auf jeden Fall irgendwie bringen musst. Du brauchst eine Komponente, du brauchst ne konkrete Komponente, du brauchst n decorator, du brauchst n konkreten Decorator und für jeden Decorator.
Du kannst dann halt mehrere Decorator drauf packen, aber du hast natürlich irgendwo immer, ich sag mal ne gewisse Art von, nennen wir es mal Overhead, den du ja irgendwo implementieren musst. Ist halt immer die Frage wohin also wogegen dieser Overhead steht ne Mhm, weil wenn du jetzt zum Beispiel sagst ne, wir wollen halt eben keine Subklassenexplosion haben, dann ist vielleicht die Subklassenexplosion sozusagen halt eher noch der. Schlimmere Overhead, den du an der Stelle hättest.
Aber da hängt es dann natürlich wieder logischerweise vom Anwendungsfall drauf ab, was theoretisch noch ne Sache sein kann. Bei den Nachteilen ist, dass es eventuell dafür sorgen kann und da muss man n bisschen aufpassen, dass die Reihenfolge der Dekorierer kann eventuell das Verhalten beeinflussen, je nachdem in welcher Reihenfolge etwas passiert. Da muss man dann n bisschen
gucken, ne? Also wenn du jetzt zum Beispiel sowas hast wie ich, sag mal irgendwas, wenn du n decorator nimmst für irgendwelche Gewinne oder so ne bei irgendeinem Jahrmarkt spiel was auch immer und du dann quasi erst plus und dann mal nimmst oder erst mal und dann plus so nach dem Motto ne also wenn du es verdoppelst oder keine Ahnung nur 2 drauf packst in welchem Kontext auch immer, dann kann es natürlich am Ende unterschiedliche Auswirkungen haben auf das Ergebnis. Ja, absolut.
Und wenn du dann sagst, ich hab n unterschiedliches Ergebnis und fragst dich wieso oder woran hat es die Link, dann ist das Debugging. Kann dann halt auch sehr anstrengend werden, weil du halt am Ende ein Objekt hast, was halt wie gesagt immer noch dein Basisobjekt so für die Software ist. Und jetzt ist irgendwo in dieser Dekorierung ja über diese Iteration des Stacks n Fehler reingekommen, weil irgendein Dekorator fehlerhaft ist.
Ja. Dann die Stelle zu finden, das ist halt dann einfach anstrengender, weil es halt wie gesagt alles aufeinander Stack gestapelt ist. Ja, und natürlich auch so ne Initialisierung kann auf den ersten Blick unübersichtlich wirken, wenn du. Angenommen du übertreibst es halt völlig ja und hast jetzt quasi sozusagen dein deine 5 dekorateuren dekoratoren und du gibst halt immer dekorateuren Dekorateure sagt Mal der so.
Und da gibst du halt in den Konstruktor New rein mit dem Vorgänger quasi der im Stapel 1 drunter liegt. Der kriegt n New von dem der da drunter liegt und so weiter bis am Ende beim letzten oder am allerersten Decorator New Base Klasse sozusagen steht und du verschachtelst das halt so, das sieht dann halt nicht schön aus und da fragt sich auch jeder was da los ist. So ne also das kann man auch schöner lösen, aber im Prinzip ist das ja irgendwo die Initialisierung am Ende. Ja.
Ja, also die kann also die du musst es halt so aufbauen und das kann halt verwirrend sein. Trotzdem muss man sagen, wenn man das ordentlich codet ja und strukturiert, dann habe ich auch ein sehr sauberes und erweiterbares Design am Ende mit diesem Pattern, was wirklich sehr flexibel ist, was kombinierbar ist und vor allem wiederverwendbar, weil es ja halt diese Eigenschaft zur Laufzeit hat. Genau deswegen kann sich das für flexible Systeme auf jeden Fall
lohnen. Definitiv also, wenn man sagt, EY, ich möchte gerne Objekte zur Laufzeit flexibel mit vielleicht zusätzlichen Funktionalitäten anreichern, ja dann ist auf jeden Fall decorator gut, wenn man denn halt eben die ursprüngliche Klasse nicht verändern möchte. Ja, das ist. Ne tolle Sache.
Dafür ist der Decorator gut wird zum Beispiel auch genutzt, ganz gerne in so Logging System Caching Systemen, vielleicht auch bei Middleware schichten, aber auch beispielsweise bei UI Komponenten. Ne, dass du zum Beispiel sagst ey du kannst ne das vielleicht kann man sich ganz gut vorstellen, du hast irgendwo ne Komponente wo du sagst du möchtest zum Beispiel ne gewisse Funktionalität weil es einfach nur ne Checkbox ist, möchtest aber zusätzlich vielleicht noch
weiß ich nicht noch was. Weiteres hinzufügen in diese Checkbox ne, um sozusagen die Funktionalität dieser Checkbox etwas zu erweitern, aber im Grunde genommen möchtest du, dass die Checkbox weiter in der Checkbox bleibt ne und dann wie gesagt, das sind so Möglichkeiten wo es halt ganz gerne verwendet wird. Ja, absolut. Und da kann man dann die Stärken auf voll und ganz ausspielen. Ja, ich glaub das war es zu dem Pattern, es ist n bisschen
komplexer schon. Aber, liebe Zuhörer, liebe Zuhörer, falls du Fragen dazu hast, schreib uns gerne, dann werden wir sie gerne beantworten, falls irgendwas nicht ganz so klar war, dann werden wir da natürlich noch mal
nachlegen. Genau. Ja. Es ist natürlich immer ein eventuell eine Herausforderung, Code mit den Worten zu erklären, deswegen auch die Analogien. Aber Liebe zuhören, lieber zur, schreib uns doch gerne auch, wann du das letzte Mal zum Beispiel n decorator Pattern angewendet hast. Welchen Anwendungsfall du dafür zum Beispiel hattest.
Und dann kommen wir da auf jeden Fall gerne in den Austausch, entweder über die Mail oder auf n. Discord beispielsweise Social Media geht auch such dir was aus, die Links zu allen Plattformen sind unten in den Shownotes, genauso wie ein kleiner Spendenling. Wenn du sagst, ey Mensch, das ist cool, der Coding Buddies Podcast, der bringt mir was, den hör ich gerne und regelmäßig und ich geb den beiden jetzt mal n bisschen was zurück, würde uns
mega freuen. Und ansonsten, wenn du sagst, nee, mach ich nicht, weil man hat ja seine Gründe, dann lass doch aber wenigstens ne kleine Bewertung da für den Podcast. Das würde uns auch mega freuen oder empfehlen den Podcast einfach weiter, das ist genauso viel wert und ansonsten würd ich sagen Tino vielen Dank für diese Folge mal wieder. Auch danke an dich, Fabi. Und ich würde sagen, wir hören uns in der nächsten Folge wieder. Bis dahin deine Korriganz gemeinsam.
Besser also. Da ziemlich ob ich ob ich Pizza. Habe ich keine. Ahnung, Pizza, Pizza komm wir gehen, wir gehen jetzt erstmal Pizza bestellen.