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.