Letztens erst gelernt hab, dass ein Räuberteller das ist, weil
irgendwer, ich weiß gar nicht mehr, wo er das bestellt und ich
dachte mir, so was willst denn du jetzt was das ist das.
Krass. Ich will das auch und dann bist
du hungrig nach Hause gegangen. Coding Buddies, Dein Podcast
rund um Softwareentwicklung und aktueller Tech News herzlich
Willkommen. Einen wunderschönen guten Tag
und herzlich Willkommen zur neuen Folge vom Coding Buddies
Podcast. Eine Woche ist wieder rum,
deswegen gibt es natürlich eine neue Folge und das passiert
natürlich nicht mit mir alleine, sondern natürlich auch mit Tino
und Tino ist auch. Hier was geht, wie geht's, wie
steht's Tino, Was geht ab? Fabi schön, dass wir mal wieder
zusammengefunden haben, wie geht's dir alles gut ja alles
gut bei mir, alles gut, alles gut, war ein bisschen
anstrengend so die letzte Woche aber.
Trotzdem ganz gut überstanden, muss ich sagen.
Ja, hab richtig Bock, dann ist ich hab richtig Bock immer
einmal morgens aufstehen und als oberstes Ziel setzen überleben
für den Tag, weil genau man weiß ja ne man stellt ja jeden Tag
nen neuen Rekord auf in Tage die man überlebt hat.
Genau, ist ja ne schöne Herangehensweise.
Ja, aber. August ist auch immer richtig
positiv, aber August ist auch immer n bisschen.
Finde ich so also in der Zeit so drumherum weißt du so im
Augustmonat und dann drumherum so kleckerweise es finde ich
immer so n ist n Monat, da ist viel los, jedenfalls ne von
daher geht. Es auch.
Also es ist natürlich, es ist natürlich Sommer und
gleichzeitig bedeutet das bei den meisten, das auch viel
geplant ist, die Wochenenden verplant sind, aber ich sag mir
dann immer lass mal nicht genervt sein davon, weil es ja
schön wenn schönes Wetter ist. Es ist schön wenn man viel
vorhat. Und auch wenn es n bisschen
stressig manchmal wirken kann oder wird, sollte man das
einfach genießen. Unbedingt schöne Zeit, da hast
du recht. Tino und in dem Sinne wollen wir
auch einfach ganz positiv an die ganze Sache rangehen, und zwar
mal gucken, was wir jetzt heute besprechen in der neuen Folge,
weil ich mein Podcast ist immer was Positives.
Das ist schön, das ist mal n Highlight.
Auf jeden Fall. Und also ich sag mal so, bevor
wir jetzt ne das Obligatorische zum Thema kommen, wollen wir
noch mal einmal ganz kurz dran erinnern, dass Liebe zu und
lieber Zuhörer, vergiss nicht diesen Podcast zu abonnieren und
diese wunderbare Glocke, die es zu betätigen, weil dann ist auf
jeden Fall garantiert, dass jede Folge die angezeigt wird
beziehungsweise dass du keine mehr verpasst, also da auf jeden
Fall dran denken. Ich hab übrigens mal
nachgeschaut. Sie existiert, diese ominöse
Glocke, und man kann draufklicken und man kriegt dann
wirklich Benachrichtigungen. Das war echt so ein Game Changer
für mich gewesen. Stark, Tino kann jetzt auch
seine Podcasts alle hören die ihr so hört, ich wurde jetzt
auch informiert, das ist. Gut, aber Tino sagte mal, worum
geht es denn heute, was steht heute so in den Staatlichern,
was steht an, worum geht's? Wir machen heute weiter mit
unserer Design Pattern Reihe und da hab ich auch ziemlich Bock
drauf, weil wir haben ja auch gutes Feedback dazu bekommen.
Ist natürlich sag ich mal ne sehr grundlegende, also ne
grundlagenreihe aber ich finde es ist cool sich einfach mit
jedem Pattern noch mal zu beschäftigen das noch mal zu
verinnerlichen sich auch mal Codebeispiele dafür anzuschauen
und egal ob man jetzt Einsteiger oder fortgeschritten ist, es
lohnt sich einfach sich damit auseinanderzusetzen, weil es
halt einfach auch. Best Practices beinhaltet in
vielen Fällen und man dadurch einfach auch seine eigene
Codequalität steigern kann. Und heute möchte ich mit dir
fabi über das Bilder Pattern sprechen und das Ziel sollte mal
so sein, wann braucht man es, wann sollte man es verwenden,
wann ist es eher ein Overkill und unnötig.
Und ich würde dabei auch gerne mit dir besprechen, was so das
klassische Pattern ist, weil wir betrachten das ja meistens immer
so wirklich lehrbuchhaft erstmal.
Also so wie es mal definiert wurde, sag ich mal.
Also die klassische Methode und möchte aber auch gerne auf
moderne Varianten mit dir eingehen.
Gerade wenn man n gewissen Frameworks, da können wir ja
Beispiele nennen, unterwegs ist, sieht man halt ähnliche
Konstrukte, die eigentlich dieses Pattern abbilden, aber
nicht so im klassischen Sinne und da möchte ich gerne mit dir
auch mal drauf eingehen, wieso moderne Interpretationen davon
aussehen, sag ich mal. Ja und wie üblich wird es
natürlich, ich hab ne kleine Analogie mitgebracht, Fabi,
diesmal hab ich eine. Wird es wiederum essen gehen wie
immer in unserer Design Pattern Reihe und schön, dass du schon
gesagt hast. Also Leute, wenn ihr keine
Essenstipps von uns verpassen wollt, abonniert diesen Podcast.
Aber das ist natürlich auch ist uns selber aber aufgefallen, wir
haben sehr viel, ich meine nehmen wir das mal hungrig.
Auf oder so also. Irgendwo muss es ja herkommen.
Ich. Weiß es auch nicht.
Das Feedback war auch einfach geil so.
Wir hatten ja gesagt, Ey, wir müssen jetzt erstmal Burger
bestellen nach einer von den Folgen und dann haben wir auch
das Feedback bekommen, so Ey, Leute wegen euch muss ich echt
erstmal Essen bestellen, supergeil schreibt uns Leute wir
freuen uns über solche Nachrichten, es zieht auf jeden
Fall einfach. Ja, auf jeden Fall, aber
definitiv. Ich würde auch am Ende noch mal
gucken, dass wir vielleicht sagen, so wie oft benutzen wir
das Pattern, wie oft glauben wir, dass das Pattern noch
eingesetzt wird und so weiter so im generellen.
Einfach, dass man noch mal ein bisschen einordnen kann, ist es
interessant für mich oder vielleicht nicht?
Aber insgesamt ist es natürlich nicht schlecht, darüber Bescheid
zu wissen, egal an welchem Punkt man steht.
Wie du schon meintest und genau ich meine, wenn wir jetzt
reingehen mal so in das Thema und sagen ne im Endeffekt gibt
es ja diese Pattern, das ist ja immer irgendwie ein gewisser
Grundgedanke, der irgendwie einen Sinn hat wo man sagt, OK,
dieses Pattern wurde ja nicht ohne Grund irgendwie ins Leben
gerufen. Und genauso ist es halt eben
auch beim Bilder Pattern und wie gesagt, in diesem Ganzen dieser
ganzen Pattern Serie sind wir auf jeden Fall immer irgendwo im
Objektorientierungsbereich. Also das bleibt eigentlich nie
aus und wenn man sich jetzt zum Beispiel mal überlegt, wenn also
das Bilder pattern, wieso ist das zum Beispiel da?
Es ist halt, wenn man das jetzt so ein bisschen zusammenfasst,
ich. Glaubt man kennt das oder man
wird auf jeden Fall irgendwann dahin kommen, dass man
vielleicht irgendwie n Objekt hat, wo unglaublich viele, sagen
wir mal, Parameter in einen konstruktor reingegeben werden.
Ne, also ich glaube als ich angefangen hab irgendwann mal zu
programmieren und mein erstes Objekt instanziiert habe, das
war glaube ich einfach nur sowas wie New My object und das war es
ne also es gab keine Parameter und im Normalfall zumindest war
es bei mir auch so. War es ganz oft so, dass eben
vielleicht die Parameter in den Konstruktor, wenn du n neues
Objekt erzeugen möchtest und sagst, ey, das Objekt was ich
jetzt habe, habe ne was ich jetzt erzeugen möchte das das
kann ich manchmal vielleicht so manchmal so erzeugen, das heißt
du gibst irgendwie n Parameter rein um halt eben irgendwie dem
Objekt noch was mitzugeben und das das kann natürlich relativ
schnell auch mal eskalieren, dass du zum Beispiel sagst, OK,
du hast jetzt vielleicht nicht irgendwie nur einen Parameter,
sondern hast auf einmal 10 Parameter, weil.
Ne, das ist so find ich auch so n so n so ne typische
Entwicklung, dass man sagt EY ich hab jetzt n Objekt und dann
denkt man sich irgendwann na ja ja irgendwie müsste ich doch das
Objekt noch so n bisschen parametrisieren können na gut OK
ich geb mal n Parameter rein und dann findet man besser hast du
auch mal Blut geleckt und denkst dir so boah geil ey let s go da
kann ich noch was reingeben und noch was noch was noch was und
irgendwann checkst du gar nichts mehr.
Gerade wenn du vielleicht noch sagst, der Parameter, der darf
da sein, aber muss auch nicht unbedingt, der ist jetzt nicht
wirklich zwingend und so weiter und dann hast du halt einfach
irgendwann so viele Felder, so viele Parameter, die du
irgendwie in den Konstruktor rein gibst, dass du halt
irgendwann sagst, keine Ahnung, ich kann das hier, ich, ich
verstehe gar nicht mehr was los ist.
Ne und es kann schnell passieren.
Ja, also du kommst halt an den Punkt, gerade auch als
Einsteigerin oder Einsteiger, dass du irgendwann Code hast,
der. Nicht mehr wirklich lesbar und
wartbar ist. Und das ist ja immer so das
große Problem, was man vermeiden möchte, ne egal wie lange man
schon codet das gilt es immer zu vermeiden, dass man in diesen in
diese Gefahr läuft sozusagen. Und was du meintest, so die
Anfänge, da muss ich auch sehr oft an unser Studium denken, wir
hatten ja auch so grundlagenkurse Einführungen in
die Informatik, hieß einer, wo wir halt auch wirklich so.
Ich glaub ich mit Java gestartet sind.
Dann hatten wir so Algorithmen und Datenstrukturen, wo man halt
einfach auch so gewisse Sachen gelernt hat, auch so auch
Pattern zum Beispiel und ich weiß noch und das ist nämlich
auch n Problem, wo man ganz schnell reinläuft, wenn man
jetzt viele Parameter hat, ja und die Sprache in der du
entwickelst, wie zum Beispiel Java, was wir hatten,
unterstützt, unterstützt, dann halt overloading ne, also dass
du den Konstruktor einfach überlebst und sagst, Na ja, OK
der ist jetzt echt sehr sehr. Unübersichtlich also überlade
ich den und sag, es gibt den einmal mit 2 Parametern.
Es gibt den mit 3 Parametern 45 kurze Pause 89 weißt du also
dann kommst du halt in so einer overload Hölle.
Und das passiert auch schnell, gerade wenn du, sag ich mal,
gelernt hast. Oh, das geht ja ja wie du
meintest. Blut geleckt.
Oh oh jetzt, jetzt kann ich meinen Code ja richtig schön
optimieren, jetzt überlade ich hier einfach alles und das sind
halt alles so Anzeichen dafür, dass irgendwas in deiner
Struktur nicht stimmt und sehr unübersichtlich wird und das
sind im Prinzip, wie soll ich sagen, Anzeichen dafür, dass du
vielleicht ja und dafür wurde das Bilder Pattern ins Leben
gerufen auf n Design Pattern zurückgreifen solltest.
Oder ein Fall, den ich noch kurz erwähnen möchte.
Was noch schlimmer ist, wenn du sagst, nein, ich möchte jetzt
mein Objekt nicht instanziieren und konfigurieren an der Stelle
mit 8 Parametern, sondern ich entschlanke das und werde jetzt
im Code verteilt irgendwo irgendwie dieses Objekt weiter
initialisieren mit zum Beispiel Settern.
Ja und das klingt halt erstmal wieder irgendwie so im Sinne der
Objektorientierung. Ja ich hab Getta und Setter ja
alles richtig. Aber dann verteilst du irgendwo
in deiner Codebasis im Prinzip die Initialisierung deines
Objekts und das ist halt auch nicht schön am Ende und
unübersichtlich genauso. Oder wenn du jetzt sag ich mal
das alles in Subklassen irgendwann auslagerst ne und du
abstrahierst dich in 1000 ebenen runter, das ist halt alles nicht
Sinn und Zweck am Ende und deswegen wurde sich sowas wie
das Bilder Pattern überlegt und ich finde.
Und da möchte ich jetzt mal auf die Analogie eingehen.
Das Bilder Pattern kann man wirklich wieder wirklich schön
mit Essen erklären. Man kann alles mit Essen
erklären. Und zwar dachte ich mir nämlich,
es geht um Essen. Ja OK, das ist jetzt so unser
Signature Move, aber ich möchte mal noch so n Beispiel dabei
nehmen was alle glaube ich so sich gut vorstellen können weil
es ne schöne Sache ist. Stell dir vor wir beide sind und
du Liebe zuhören Liebe zuhören natürlich auch wir 3 sind
eingeladen zum Essen und es gibt n.
Buffet das ist geil. Buffet mag jeder ne n schönes
Buffet mit ganz vielen leckeren Sachen und man kann sich das so
einzeln aussuchen was man haben will, man kann die Menge
bestimmen Oh das war super lecker, das esse ich in der
nächsten Runde noch mal. Weißt du diese Gedankengänge die
man dann hat? Ja, du bezahlst Geld dafür, dass
du dir so viel Teller holen kannst, wie du willst, aber
holst dir maximal 2. Ja, ich will.
Jetzt sagen, ich lass uns mal nicht in diesen All you can eat
Gedanken, da will ich gar nicht unbedingt.
Und jetzt stell dir vor, du gehst los zum Buffet und
möchtest dir jetzt Essen holen. Freust dich schon so richtig
auswählen zu können, dir erstmal alles angucken zu können und
dann gezielt Sachen auf deinen Teller zu machen, zu sagen, ich
möchte ein bisschen davon und ein bisschen davon und nehme ich
eine Vorspeise, erstmal gucken was für Vorspeisen es gibt, so
weißt du und jetzt steht da aber einer du kriegst einen Teller.
Beziehungsweise du kriegst nicht mal den Teller so klassisch,
dass du einen Teller in der Hand nimmst und Losgehst, sondern da
steht jetzt eine Servicekraft und sagt, so was darf es denn
für sie heute sein? Du denkst dir so, naja, ich
möchte jetzt einen Teller gerne haben und zum Buffet gehen und
das stückweise für mich hier klären was ich essen möchte.
Nein du möchtest jetzt bitte sagen was du haben möchtest vom
Buffet und. Und die Servicekraft wird dir
diesen Teller zurecht machen und ihn dir geben.
Das heißt, du gehst nicht wirklich direkt zum Befehl,
sondern du kriegst zum Zeitpunkt, wo du das entscheiden
musst, den ganzen Teller. Ja, die Servicekraft ist der
Builder. Nein, warte, warte, die
Servicekraft ist im Prinzip, erstelle mir einen Teller mit
dem Essen erstmal nur, also du musst genau an der Stelle
entscheiden. Was möchte ich haben jetzt
sofort, du kriegst jetzt einen Teller und da ist das drauf was
du sagst und da sind wir ja bei unserem Konstruktor mit den
ganzen Parametern. Vorspeise ja nein, welche
Vorspeise möchtest du noch ein Getränk drauf haben?
Jetzt vielleicht nicht auf dem Teller, wenn du jetzt ein
Tablett hast oder so ne und so weiter und das fühlt sich doch
einfach in diesem Szenario überhaupt nicht richtig an was
du machen möchtest ist ja Schritt für Schritt dir diesen
Teller aufzubauen, du möchtest ja gucken.
Ist denn überhaupt noch was da? Was für Vorspeisen gibt es denn
ja auch, doch das sieht gut aus, ich mach mir mal nen Löffel
drauf und dann gehst du weiter und so füllt sich nach und nach
dein Teller, das heißt dein Objekt wird nach und nach
definiert und wenn du zum Platz gehst, hast du deinen fertigen
Teller mit dem Essen deiner Wahl in der Menge deiner Wahl, sogar
in der Reihenfolge aufgetan deiner Wahl so gesehen und gehst
zu deinem Platz und hast deinen fertigen Essensteller OK, also
das ist doch eigentlich die bessere.
Art und Weise, wie du an einem Buffet essen möchtest.
Okay also du hast quasi gesagt der die Bedienung die das auftut
ist sozusagen der Konstruktor, den du halt in einem bestimmten
Raster sozusagen vor wie vorgegeben, so sag ich jetzt
mal, bedienen musst. Wenn du aber zum Beispiel das
einfach selber dir auftun kannst, wie es ja beim Buffet
eigentlich normalerweise der Fall ist, dann bist du im
Endeffekt der Bilder, der dir am Ende das Objekt Abendessen baut.
So die Richtige, ja, zum Beispiel den Teller, den
Essensteller. Ja, genau.
OK, und alle solche Sachen wie Optionalität, wie du schon
meintest ne, gibt es überhaupt noch Nachspeise die ich haben
möchte weiß ich ja zu dem Zeitpunkt gar nicht, wenn ich
nicht mal im Buffet stehe, es kann ja sein, dass die gerade
gewechselt wird oder leer ist, dann kann ich ihm vorne ja
sagen, ja ich möchte jetzt bitte Dessert das und das und er denkt
sich so OK aber ich weiß nicht ob es da ist.
Also du kannst ja so optionalitäten dann wirklich
schwer überblicken. Und vor allem warten in dem Fall
dann auch ne. Das wär aber auch blöd, wenn du
da extra ne Kraft hast die das macht und ich würd gern das
keine Ahnung ob es das gibt. OK kommt einfach mit dem
Lernteiler wieder zurück es tut mir leid Sir wir haben es nicht
Black. Ja, aber find ich auf jeden Fall
ganz gut. Ist ne schöne Analogie und
stellt im Endeffekt auch genau das dar, was so n so n Builder
dann am Ende macht. Das heißt?
Du hast im Endeffekt ein. Du hast im Endeffekt für mich,
ich würde es jetzt so sagen, dass das Builder Pattern so eine
Art, ich nenne es jetzt mal Helper ist, der dir am Ende dein
gewünschtes Objekt nach deinem Gusto sozusagen zusammenstellt,
richtig? Genau.
Ja. Also wir können ja mal.
Auf das klassische Bilder Pattern so lehrbuchartig drauf
eingehen. Also es ist auch n creational
Pattern, das heißt es passt noch ganz gut zu den bisherigen und
im Prinzip geht es darum komplexe Objekte wie zum
Beispiel ein Essensteller, wo ganz viele teilgerichte sag ich
mal drauf sind, weil im Buffet machen wir uns nichts vor, man
macht sich von allen bisschen was, ja und wie kann ich so n
Objekt quasi so ne komplexen. Objekte kontrolliert erzeugen
und damit beschäftigt sich das Bilderpattern und im Prinzip
möchtest du genau das voneinander trennen, diesen
Konstruktionsschritt und den Repräsentationsschritt, also
diesen fertigen Teller zu haben. Das willst du voneinander
trennen, die Herstellung mit der Repräsentation am Ende.
Definitiv. Und wir haben es ja schon
gesagt, es ist auf jeden Fall definitiv ideal, wenn man halt
eben. Viele, auch optionale Felder hat
um das jetzt mal an deinem Beispiel anzubringen, möchte ich
jetzt vielleicht noch n Dessert mitnehmen vom Buffet oder nicht?
Ne, dass man halt sagt OK, also zum Beispiel ich bin jetzt nicht
ganz so n Dessert Typ so manchmal ja, aber meistens eher
nicht, dann nehme ich mir lieber noch mal Nachschlag, so nach dem
Motto ne oder halt zum Beispiel wenn man unterschiedliche
Ausprägungen vom Objekt hat. Also wenn du jetzt diesen Teller
nimmst und sagst ne OK du nimmst jetzt einmal irgendwie.
Weiß nicht von Angebotsplatte 1 und 2 und beim nächsten Mal 1
und 3, weil 1 so gut geschmeckt hat.
Willst du aber noch was Neues ausprobieren, ne so, dann hast
du im Endeffekt durch das Gleiche durch den gleichen, also
durch dieses durch diesen Bildern das durch diesen
Bildern, durch diesen Bilder das gleiche gebaut, ne das gleiche
Objekt mehr oder weniger, aber mit einer anderen Ausprägung
genau was ich auf jeden Fall ganz interessant fand war, weil
du jetzt auch gesagt hast, selbst wenn man jetzt
fortgeschritten ist, kann man ja noch n bisschen was lernen, ne?
Und ich fand es ganz interessant, weil jetzt auch,
als wir die Folge vorbereitet haben, fand ich es ganz
spannend, weil ich sag mal der Builder, so wie ich ihn zum
Beispiel verwende. Oft war nicht der klassische
Builder, sondern halt eher einen, den wir dann auch gleich
noch mal beschreiben werden, aber ich fand das auf jeden Fall
super spannend, dass weil irgendwie man verwendet das aus
einem bestimmten Grund, das sagen wir auch gleich noch mal.
Vielleicht wieso ich den so dann im Endeffekt kenne, aber es gibt
ja noch wirklich diesen diesen richtig klassischen Bilder, weil
du ja auch gerade vom klassischen Bilder Pattern
geredet hast und auch am Anfang meintest.
Laut Lehrbuch willst du mal kurz sagen, was ist denn laut
Lehrbuch, bevor wir dann am Ende, vielleicht auch später
noch mal darauf hinkommen, wie ich ihn zum Beispiel auch oft
verwende oder wie ich ihn eigentlich auch kenne.
Ja, ich, ich weiß, worauf du hinaus willst.
Deswegen haben wir es ja mit reingenommen, weil es ist jetzt
wirklich mal der der klassische Aspekt dahinter ist, dass du
sagst, OK, das Pattern braucht auf jeden Fall ein eine
Produktklasse, ne, also ein Builder.
Das Pattern an sich dreht sich natürlich immer um ein Produkt
am Ende, was ich erzeugen möchte, ja, also wovon ich
Objekte instanziieren kann und in unserem Fall wäre das ja
jetzt der Essensteller an unserem Beispiel.
Ja, das ist das Produkt, was wir quasi herstellen wollen.
Das heißt, du hast jetzt erstmal eine klasse Essens Teller ja,
Plate irgendwie, wie auch immer man das denn nennen möchte, dann
wirst du ein Builder brauchen, aber, und das ist jetzt der
Unterschied was du meintest, für dich war jetzt ein Builder in
der Implementierung wie du es verwenden würdest.
Kein Interface, aber im klassischen Sinne ist der
Builder ein Interface, aber. Und zwar ein Interface mit
Konstruktionsschritten wie schaffe ich es, diesen Teller zu
erzeugen? Ne, also sowas wie füll die
Vorspeise auf füll die den Hauptgang auf, also da sind im
Prinzip Schritte, also Funktion drin definiert wie sich das
Produkt am Ende zusammensetzt. Ja.
Ja, und dann ganz klassische Objektorientierung habe ich
jetzt ein Interface und ich brauche natürlich auch eine
Implementierung davon. Das heißt, ich implementiere
dann zum Beispiel den Italian Food Builder.
Ja, und mal wieder, das hatten wir schon mal.
So ähnlich das Beispiel, das heißt, ich sage jetzt von diesem
Bilder, implementiere ich eine italienische Variante, das
heißt, ich gehe ans Buffet und wähle jetzt gezielt,
implementiere ich quasi die Funktion, nimm Vorspeise und
sage, die ist so implementiert, dass ich mir jetzt antipasti
nehme. Zum Beispiel von den Vorspeisen,
Hauptgang, Lasagne. Da gibt es jetzt so Lasagne zur
Auswahl, das heißt, ich implementiere meine Bilder so,
dass der sagt, da nimmst du jetzt bitte ne Lasagne, ja und
Nachtisch, Tiramisu, was anderes fällt mir jetzt gerade nicht ein
und dann habe ich quasi, ich hoffe das passt alles für die
italienische Küche, dann habe ich quasi einen Essensteller im
italienischen Flair. Erzeugt ne wenn ich diesen
Bilder verwende und dann gibt es ganz ganz klassisch.
Das habe ich aber selten so gut wie gar nicht gemacht bisher und
das werden wir später erklären. Warum gibt es noch eine weitere
Klasse und zwar eine Art Director und der ist jetzt dafür
da, im Bilder noch festzulegen, in welcher Reihenfolge ich das
mache. Ja, ja, also ich habe jetzt die
einzelnen Schritte, ich weiß, wie ich diesen Teller
zusammenbauen kann, aber die Frage ist, in welcher
Reihenfolge möchte ich das machen, ist mir das wichtig.
Ja, also ich glaub die wenigstens die gehen los und
holen sich erstmal n Dessert das ich mein was was wär das denn
nein sondern ich geh jetzt wirklich die so n Dessert ist
Quatsch Dessert so n Befehl ist ja meistens auch so aufgebaut,
dass du vorne erstmal ja Vorspeisen hast.
Den Hauptgang und hinten am Ende stehen denn die Desserts und
genauso könntest du jetzt in deinem Director vorgeben, das
ist im Prinzip dann der Aufbau des Buffets, dass du erstmal zu
den Vorspeisen gehst, die Funktion Ausführst, dann
Hauptgang und dann Nachtisch und am Ende vielleicht noch weiß ich
nicht, was man halt mit reinnehmen möchte noch so und
das wäre so gesehen das klassische Bilder Pattern und in
deinem Code den du dann hast. Also wenn du das jetzt verwenden
möchtest, zum Beispiel, hol mir einen Essensteller oder bau mir
diesen Essensteller auf, kannst du ja dann entscheiden, was für
eine Art Teller du möchtest. Das ist dann die Flexibilität
hinter dem Pattern, dass du sagst, ach, ich nehme den
italienischen Teller, das heißt ich weiß, ich muss da jetzt
hingehen, ich nehme die Antipasti und so weiter das
heißt, ich habe meinen Bauplan und wenn ich einen Director noch
verwende, dann sagt er auch noch in der Reihenfolge machst du
das. Und dann kriegst du am Ende
quasi Objekt Play zurück, mit gefüllt mit deinem Essen.
Das heißt, dieses Objekt hat denn zum Beispiel ja weiß ich
nicht irgendeine Funktion wie Get Get Starter oder so, und da
kommt dann zurück antipasti ne, also wenn du jetzt irgendwie das
überprüfen möchtest, dass du siehst, ach auf meinem Teller
liegt eingelegte Oliven, weiß ich, was ja, ja, genau.
Also ich ich bei hab es auf jeden Fall.
Also ich weiß auf jeden Fall was du meinst.
Wie gesagt, ich fand es halt, fand es halt spannend, dass ich
halt wenn ich Bilder verwendet hab hab ich den so halt
eigentlich nie verwendet. Ne das ist irgendwie ganz
spannend und deswegen das meint ich so man kann halt immer auch
noch mal auch was lernen wenn man jetzt zum Beispiel auch
schon fortgeschritten ist halt ne und ist halt irgendwie
interessant wie das eigentlich zustande gekommen ist.
Ich find es aber auch n bisschen.
Ich weiß nicht, bisschen schwierig diese Steuerung dann
über so n Director zu machen, weißt du?
Ja, es ist halt Fakt ist, das können wir auch bei den
Nachteilen. Also wir wollen ja noch vor und
Nachteile beleuchten schon mal n bisschen vorweggegriffen diese
klassische Implementierung fühlt sich halt schon so n bisschen
nach Boiler Plate Code an. Das heißt, du musst halt viel
Struktur aufbauen, um das Nutzen zu können.
Wie du zum Beispiel meintest n Director extra implementieren,
um ne Reihenfolge vorzugeben. Ja genau, der am Ende ja auch
nur aufruft und sagst Ey hier ist n Bilder und jetzt führ mal
bitte in den Reihenfolgen die ich dir sage, die auch wieder
implementiert sind. Die Aufrufe des Bilders durch
sozusagen ja. Also wie gesagt, im Endeffekt
macht es schon Sinn. Kann man auch noch mal drauf
eingehen, aber auch nicht immer ne.
Aber Fakt ist und das ist ja genau der.es gibt ne Menge
Vorteile von so einem Bilderpattern, die wir auch
schon mehr oder weniger angeschnitten haben.
Also du hattest ja auch schon gesagt es soll ne Trennung von
Objektstruktur und der Konstruktionslogik sozusagen da
sein und das ist im Endeffekt ja auch mehr oder weniger das
Hauptding was in Bilderpattern macht und wofür es halt eben
steht, ne also. Ne Produktklasse muss halt nicht
wissen wie sie zusammengesetzt wird.
Ne, also das Buffet selber denkt sich so mir egal.
Mach n Abendbrot draus, so nach dem Motto.
Der Keller denkt sich egal. Genau.
Wie wie das Essen drauf kommt. Hauptsache ich bin nicht leer.
Richtig. Und selbst wenn er am Ende leer
wäre, dann hat die Person vielleicht keinen Hunger.
Ja, wie heißt das? Das ist das so n Räuberteller
oder so nennt man das da oder das find ich immer super witzig
n Räuberteller der leer ist, weil du ja eh nur von den
Nachbartellern Runternimmst. Tatsächlich muss ich ganz kurz
off topic sagen, dass ich das letztens erst gelernt hab, dass
es n räuberteller das ist, weil irgendwer.
Ich weiß gar nicht mehr, wo hat das bestellt und ich dachte mir,
so was willst n du jetzt was das ist das krass, ich will das
auch. Und dann bist du hungrig nach
Hause gegangen. Und dann hab ich erstmal
gemerkt, ah OK. Gut, das ist also n ja gut.
Macht Sinn. Aber es ermöglicht halt eben
auch ne gute Architektur, ne. Gerade im Single Responsibility
Principle, wenn man darauf das Ganze jetzt Münzen möchte, weil
du im Endeffekt sagst, OK, das Objekt selber kannst du zwar
erzeugen, aber wie das Objekt erzeugt wird, das ist diese
diese. Verantwortlichkeit liegt nicht
beim Objekt, sondern halt eben in dem Fall dann beim Bilder.
Ne ja ja, ansonsten hast du halt wie gesagt auch Flexibilität in
den Objekten beziehungsweise in den in den in den nicht in den
Objekten in den Feldern in den optionalen Feldern.
Eventuell wenn du optionale Felder hast.
Das ist natürlich noch gut, weil ich weiß nicht ob man das schon
bestimmt, kennt man das? Gerade wenn du zum Beispiel
Funktionen hast. Es gibt ja genügend Sprachen,
die Funktionen anbieten, wo du zum Beispiel auch optionale
Parameter mitgeben kannst. Wenn du das bei Konstruktoren
hast. Es wird irgendwann schwierig, es
wird irgendwann anstrengend, weil du brauchst eigentlich, je
mehr du von diesen optionalen Dingern hast, auch wenn du es
natürlich im im Bilder einbauen kannst, ist es immer so n
trotzdem am Ende ne Frage. Wie gut ist es, optionale Sachen
zu haben, weil je mehr optional du hast und je mehr du
vielleicht Abhängigkeiten von den optional ne ich kann das
mitnehmen und wenn du das mitnimmst, dann muss aber auch
das dabei sein, so als Beispiel bläht sich halt ne Dokumentation
ewig auf, also du brauchst am Ende irgendwann ne Dokumentation
um irgendwann zu verstehen was da los ist.
Ne, so n Builder kann dir da auch in im Guiding so n bisschen
helfen, trotzdem ne auch gerade wenn du jetzt zum Beispiel so n
Director beispielsweise hast, der dir dann sagt ne.
OK, du willst das und das machen, aber das funktioniert so
nicht. Wenn du das nicht hast
beispielsweise ne ist so n bisschen angeleitet das Ganze.
Was natürlich jetzt vielleicht n bisschen naheliegend ist, aber
halt auch wirklich n Vorteil dabei ist, dass du
wiederverwendbare Konfiguration hast.
Ja, du kannst ja so gesehen das buffetbeispiel du baust dir
deinen Teller zusammen, du isst ja und denkst dir.
Oh Mann, das war der Hammer, ich möchte genau den gleichen noch
mal essen. Dann gehst du los und füllst dir
den Teller noch mal so auf und isst den dann halt noch mal.
Und das spiegelt halt auch ein Bilderpad dann wieder.
Du kannst natürlich so wie du das Objekt aufgebaut hast, es
erneut aufbauen, ja, gerade wenn du jetzt auch noch so ein
Director verwendet zum Beispiel, du kannst der exakt genau das
gleiche ja Objekt wieder aufbauen, was auch ein Vorteil
ist. Das auf jeden Fall, ja, also.
Das fand ich zum Beispiel auch mal ganz interessant.
Also wenn wenn ich jetzt mal kurz ein Beispiel aus dem Leben
erzähle. Jetzt geht es los.
Also ich hab zum Beispiel mal Bilder Pattern verwendet in
einem am Arbeitskontext, da wurde so eine so eine Art sagen
wir mal Test Data Bilder haben wir geschrieben, ne, da konntest
du dann aus diesem Test Data Bilder, das war natürlich jetzt
ein bisschen größeres Ding, es war auch.
Bisschen wahrscheinlich zu krass über alles im in den ganzen
Tests drüber gebügelt, aber Fakt war, dass es auf jeden Fall sehr
sehr gut funktioniert hat, dass du gesagt hast, du möchtest
jetzt zum Beispiel n bestimmtes Objekt erzeugen, ne mit
bestimmten befüllten Attributen, weil du halt gesagt hast.
Also weil zum Beispiel in dem in prozessschritten sag ich jetzt
mal, wenn du so n Objekt hattest, konntest du das so mit
mehreren Prozessschritten erweitern, ne, so kannst du es
dir ungefähr vorstellen. Und wenn du jetzt zum Beispiel
einen bestimmten Prozessschritt testen wolltest, dann musste man
ja nicht noch mal alles vorher machen, sondern der Test
databuilder war dann halt im Endeffekt in der Lage zu sagen
okay, nimm mir mal so ein Objekt, mach mal dies, mach mal
das, mach mal das damit und dann bist du an einem Punkt und
kannst quasi direkt weiter testen.
Das Schöne daran war, du konntest relativ schnell auch im
in deinem Test lesen, was ist schon mit diesem Objekt
passiert. Dass du dann sozusagen auch
generell den Test ganz gut lesen konntest.
Und dafür war es halt einfach hilfreich, dass du so sukzessiv
bestimmte Objekte, die du brauchtest, halt eben
vorbereiten konntest für deinen Test.
Also das hat auf jeden Fall, das war ein super Beispiel, fand ich
zumindest dafür, wann so ein Builderpad dann schon mal ja gut
funktioniert hat oder gut gute Arbeit geleistet hat, absolut.
Ist ein gutes Beispiel. Ich finde es aber auch gut, dass
du sagst, dass das Ganze ziemlich groß geworden ist und
man das Halt kontrollieren musste bei all den Vorteilen
haben wir natürlich, denn das zum Beispiel auch als Nachteil,
also Fakt ist, durch diese erhöhte oder verbesserte
Struktur hast du auch mit dem klassischen Bilder Pattern mehr
Code, zum Beispiel hat man ja gesehen, wie viele Klassen man
braucht oder auch Interfaces um überhaupt diese Struktur
aufzubauen. Ja, und das ist auf jeden Fall
Nachteil, weil du erstmal wesentlich mehr Code erzeugst.
Und wenn ich jetzt aber sehr einfache Objekte habe, ja, also
ich rede nicht mal davon, dass es zum Beispiel keine Parameter
gibt, ja, dass das halt statische Objekte irgendwie sind
in dem Kontext, sondern vielleicht 23 Parameter und
keine optionalen zum Beispiel. Dann bin ich an einem Punkt, wo
man abwägen muss, ist das nicht einfach zu viel Overhead?
Ja, also ich kann ja schnell diese oder schnell ist schnell
ist das falsche Wort einfach diese Objekte erzeugen ja und
gerade auch wenn Performance wichtig ist.
Wenn ich sehr viele Objekte erstelle, ja, dann ist
vielleicht ein Builder Pattern auch nicht das Richtige, weil
das ist ein wichtiger Punkt. Ich erzeuge ja nicht einfach nur
ein Objekt, sondern. Ich rufe Funktion von Objekten
auf, um ein Objekt zu erstellen. Das ist das ist n feiner, also
der sieht jetzt nicht so riesig aus, der Unterschied aber im
Performance Kontext kann das enormer Overhead bedeuten, weil
ich nicht einfach nur n Objekt instanziiere, sondern sehr viele
Funktionsaufrufe eventuell habe um das finale Objekt zu bekommen
was ich brauche und wenn ich jetzt sehr sehr viele Objekte
davon brauche zum Beispiel es ist n riesen Befehl, da sind
ganz ganz viele Leute und ich hau da tausende Teller raus, so
in der Implementierung. Jetzt ja.
Und je nachdem, wie Feingranular die Auswahl am Befehl ist,
wieviel Funktionen das sind, nicht einfach sowas wie nimm
Vorspeise, sondern nimm bisschen davon, ist eine Funktion
bisschen davon also übertrieben ja und du hast ganz ganz viele
Funktionen die da aufgerufen werden, dann ist das n ziemlich
großer Overhead am Ende. Definitiv.
Also das ist auf jeden Fall n guter Punkt, woran ich
wahrscheinlich auch nicht als erstes gedacht hätte, aber es
ist auf jeden Fall sehr, sehr wichtig, dass man da, also dass
man. Dem Halt also, dass man bewusst,
dass es einem bewusst ist. So.
Und was ich jetzt vielleicht nicht unbedingt als Nachteil
hinstellen würde, was aber auch wichtig ist zu sensibilisieren,
finde ich, ist beispielsweise, dass man durchaus wissen sollte,
dass man relativ, dass es auch durchaus relativ schnell möglich
ist, eine Menge Logik in diesem Bilder rein zu ballern, so, das
heißt, so ein Bilder kann im. Worst Case auch relativ schnell
komplex werden eine hohe viel Logik haben und vielleicht auch
irgendwann das Ganze schwierig machen zu warten.
Also natürlich nur, wenn man nicht wirklich aufpasst.
Wichtig ist oder was ich versuchen will zu sagen ist man
muss. Gucken, wie man Bilder
implementiert dass es nicht komplett ausufert, dass man
nicht einfach nur sagt, Ach komm, ich hau jetzt hier noch
was dran, ich hau jetzt da noch was dran, sondern wirklich immer
noch die Sinnhaftigkeit dahinter zu packen und zu sagen, ist es
jetzt gut, passt das noch zu meinem Konzept und ist das jetzt
nicht vielleicht Missbrauch ich das ganze jetzt nicht zum
Beispiel ne, also das ist halt immer n bisschen und dass man
halt auch regelmäßig das ganze Refact hat sollte man n Punkt
kommen wo man sagt, Oh was ist denn hier los, das ist ja
irgendwie ich ich ich versteh es nicht mehr oder was auch immer
ne also das sind halt wichtige Punkte.
Dem man sich irgendwie Bewusstsein sollte, weil das
kann natürlich auch ohne Bilderpattern passieren.
Nur meine Erfahrung ist, dass wenn du ein Bilderpattern nutzt,
dann kann es halt relativ schnell sein, dass vielleicht
auch gerade wenn man im Team arbeitet, alle irgendwie was da
mit Reinklatschen und draufpacken und ach, wir haben
ja hier ein Bilder für, da mache ich dies noch, da mache ich das
noch und am Ende hast du zwar ein Bilderpattern was wenn du
gutes Bilderpattern hast. Dann hilft dir das richtig gut
weiter. Aber ein schlechtes Bilder
pattern oder 1 was irgendwann völlig verhackstückelt wird oder
für verschiedene Zwecke missbraucht wird, das bringt
dich irgendwann halt auch nicht mehr wirklich weiter und da muss
man finde ich ein bisschen aufpassen am Ende.
Ja, das ist ein sehr guter Punkt, weil das klassische
Bilder pattern, wenn man das halt wirklich falsch nutzt, wie
du meintest, hast du halt zum Beispiel eine fehlende
Validierung deines Objekts am Ende.
Ja, weil diese Funktionen, die du aufrufst, um dein Objekt
zusammenzubauen, müssen ja nicht aufgerufen werden.
Genau, und wenn du dann nicht aufpasst, hast du halt
undefinierte Werte da drin oder kannst gar nicht so weiter
arbeiten mit dem Objekt wie du es gerne machen möchtest.
Das knallt dann irgendwo in der Software, da muss man halt
aufpassen, dass man halt auch wirklich sicherstellt, dass
gültige Objekte sozusagen am Ende rauskommen.
Ja, genau das ist auf jeden Fall ein sehr wichtiger Punkt, den du
da genannt hast. Ich mein, das kannst du
theoretisch ja am Ende immer machen, aber wie gesagt führt
auch am Ende wieder zur Logik ne, die dann halt eben auch
vielleicht wieder abgetestet werden sollte und so weiter und
sofort ne. Das ist natürlich, wie gesagt,
muss man halt und das das Ding ist natürlich am Ende auch
wieder so und deswegen sagen wir eigentlich, in jeder Folge
probiert Liebe zu Liebe, zuhören, probieren, einfach das
auch mal aus, wenn du zum Beispiel sagst, ich hab noch nie
n bilderpad dann ausprobiert, einfach mal implementieren,
einfach mal gucken für n entsprechenden Zweck, vielleicht
auch einfach für n konstruiertes Beispiel einfach mal um das
Feeling dafür zu kriegen, zu sagen, wie ist denn das jetzt
so, macht es Spaß oder nicht. Zum Beispiel Unser Befehl
Beispiel genau. Ich würde gerne, weil du, du
hast es schon angesprochen, so hey, so in der Form nutzt.
Also ich nutz n Bilder pattern aber gar nicht so im klassischen
Sinne, ja oder ich hab es sehr oft in Frameworks in anderer
Form gesehen und da möchte ich jetzt so zum Schluss noch mal
drauf eingehen, bevor wir sag ich mal so n Fazit noch ziehen.
Ja wie sieht das so in modernen Frameworks aus und wie wird da
das Bilder Pattern verwendet und da spricht man halt oft von dem
Fluent Fluent Bilder und. Nicht Pattern, Flur und Bilder
und das kann man so ein bisschen sagen.
Klassiker neu interpretiert so also moderne Umsetzung dieses
Klassikers. Ja, und das findet man halt oft
in modernen Code oder modernen Frameworks und dabei ist es
quasi der gleiche Grundgedanke, aber einfach schlanker
umgesetzt, man hat sich halt gedacht, dieses Interface und
ein Director. Ich weiß nicht, das ist halt so
viel spoilerplate Code am Ende. Ne weiß ich nicht und deswegen
hat man einfach gesagt oder geht man nen anderen Weg und sagt OK
wir lassen das Weg und wir verwenden die Methodik der
Method Chaining ja also ne Verkettung an Funktionsaufrufen
und das hat 100 Pro jeder früher oder später irgendwann mal
gesehen ja, aber vielleicht nicht.
Aktiv drüber nachgedacht warum mach ich das hier eigentlich
gerade? Warum sieht das so komisch aus?
Vielleicht, wenn man das zum ersten Mal sieht, ne, dass du so
ganz viele Funktionen verschachtelst, aber
verschachtelt im Sinne wirklich verkettest, also immer wieder
das Ergebnis einer Funktion gleichzeitig darauf wieder ne
Funktion aufrufst und dann bilden sich so so Ketten sag ich
mal und am Ende kriegst du n Ergebnis raus.
Ja und genauso nutzt man denn quasi im Fluent Builder.
Diese Möglichkeit, also diese Methodik um ein Builder Pattern
umzusetzen, das heißt, man kann sich das jetzt so vorstellen,
man nimmt so diese klassische Methodik weg, man hat immer noch
sein Produkt, ja, also du hast immer noch deinen Essensteller
und du hast auch immer noch ein Builder, aber jetzt
instanziierst Du einen neuen Builder für deinen Teller.
Ja, also zum Beispiel einfach New Plate Builder, rufst den
Konstruktor auf. Und machst dann aber und
verwendest dann quasi gleich direkt die Funktion des Bilders.
Das heißt, du machst dann zum Beispiel ja, also in klassischen
Sprachen sagst du dann Punkt mit Vorspeise und gibst ein
Parameter rein. Antipasti so, das heißt, du
sagst, ich möchte auf diesen Teller die Vorspeise, Antipasti
und jetzt sagst du aber wiederum aber Punkt mit Hauptgang.
Lasagne? Ja einfach noch verkettet da
dran und so weiter und verkettest dann komplett deine
Konfiguration und am Ende sagst du keine Ahnung Get Plate und du
kriegst dann wirklich ein Plate Objekt mit diesen Eigenschaften
zurück. Ja, oft wird das ja zum Beispiel
auch dann so gemacht. Also ich kenn das halt so, aber
das erste Mal, als ich das auch gesehen hab oder was ja auch oft
gerne gemacht wird, ist dann so n punktbild ne, das wird dann
oft gemacht. Ganz klassische.
Genau, also das wird halt vielleicht ich.
Ich hab frag mich auch so, also gerade wenn du sowas machst find
ich sowas wie n getplate dann irgendwie schöner ne, aber ich
glaube, dass so n Punkt Bild halt oft gemacht wird um halt
eben auch wirklich zu signalisieren Ey hier wird n
bilderpattern jetzt gebaut. Ja genau, also hier wird es
erstens jetzt gebaut und zweitens hier ist es ist
sozusagen n bilderpattern was ich also ne so n fluent Bilder
dann aber was ich am Anfang interessant fand wo ich das das
erste Mal gesehen hab ne es ist keine Ahnung.
Das ist vorgestern gewesen sein. Ja, in der Vorbereitung hier.
Keine Ahnung. So im Studium Anfang des
Studiums irgendwie so ne im ersten Drittel und dann denkst
du dir so hä ey ich versteh grad nicht wieso kann er denn jetzt
sagen mach mal also nimm gib mir eben Bilder mit was weiß ich was
hast du gesagt with starter with main with the sair oder was auch
immer ne und wie wie kann es sein, dass er jetzt sozusagen.
Wie, dass du immer was reingeben kannst und dann diese Funktion
auf sich also immer wieder aufrufen kannst.
Also wie geht das? Das hat da hab ich hab ich
irgendwie nimmer genau bis ich dann irgendwann halt auch
dahinter gekommen bin und dann gesagt hab OK der Builder ne
dieser über den wir gerade geredet haben, der gibt halt
einfach, also der Return des Builders ist immer This, also
immer in sich, also sich selbst. Also wenn man jetzt in Java
spricht, ich glaub wir hatten Java vorhin angesprochen,
deswegen ist das in meinem Kopf das Bild.
Aber ergibt immer sich selbst als Objekt zurück, was bedeutet,
dass wenn du ne Funktion aufgerufen hast, dass die also
auf einem Objekt und dieses Objekt sich selber wieder
zurückgibt, kannst du natürlich logischerweise als Return Value
weiter auf diesem Objekt arbeiten, was eben wiederum die
Funktion hat, ne. Genau.
Und du hast alle Konfigurationen, die erledigt
sind. Abgespeichert im Prinzip.
Du kannst halt genau dieses Schritt für Schritt am Befehl
lang gehen. Ja und dir dein Essen auftun
sozusagen, und du sparst dir halt den Director, weil du mit
diesen Funktionsverkettungen die Reihenfolge der Kette, dir den
Director ja quasi ja wird ja obsolet, weil du ja dann in dem
Falle schon die Reihenfolge festlegst genau ja, und du
brauchst halt auch kein Interface wie n Builder
aussieht, weil der Builder hat jetzt die Funktion und ich kann
jetzt. Fluent ja, also wirklich einfach
selbst definieren, wie ich da die Aufrufe mache.
Ja. Obacht, wieder im Thema
Validierung am Ende ne es gewährleistet jetzt keiner, dass
ich alle, also alle Funktionen in meiner Kette drin hab.
Ja richtig, das ist halt jetzt wirklich wieder dieser
Validierungspunkt am Ende, ich find das eben, wo wir aber zum
Beispiel am Ende ganz kurz, sorry in dieser Bild wie du
meintest ja klassisch abfangen kannst.
Genau kann man auf jeden Fall machen, ist halt die Frage
wieviel man dann am Ende sozusagen zulässt.
Ne. Oder halt eben auch nicht.
Aber, und das finde ich ja, auf das ist halt auf der einen Seite
oder auf der haben Seite ist halt eben das, sowas ist super
lesbar oft ne also wenn du es richtig machst, dann kann ich es
wirklich genau, dann kannst du halt den Code wirklich relativ
einfach verständlich lesen, also wie als wäre es ein Buch sag ich
jetzt mal auf der anderen Seite könntest du aber auch wenn du es
falsch anwendest dir denken, so was passiert denn da eigentlich
gerade weil wenn du zum Beispiel diesen.
Plate Bilder nimmst zum Beispiel und sagst Whist Data Salat,
Whist, Data Antipasti, Whist Data.
Dass das dann weißt du auch, zum Beispiel nicht hundertprozentig,
füg ich jetzt mehrere Data hinzu, also kann ich jetzt n
Salat und antipasti essen oder sag ich mir zum Beispiel oder
überschreibst du das oder ist das überhaupt valide, zweimal
woist Data aufzurufen? Also du könntest ja einfach
hundertmal Woist Data aufrufen und sagen und ab.
Dafür und ja klar, und du weißt halt natürlich nicht erstmal von
außen. Addet er das sozusagen, hab ich
jetzt ne Liste an Starter oder überschreibe ich die wie du
gerade meintest? Das ist halt genau das Ding,
denn dabei, ja und? Das ist halt dann im Endeffekt n
bisschen die Kunst zu sagen, OK, wie baut man jetzt so n Bilder
auf oder so n Flur und Bilder in dem Fall jetzt in diesem
konkreten, dass er auch wirklich irgendwie, sagen wir mal schön
aussieht, dass er ne beziehungsweise nicht nur schön
aussieht, sondern dass er halt eben auch gut implementiert ist
und sowas vielleicht irgendwie. Intuitiv dann eben kapselt, aber
ein bisschen wissen wird immer vorausgesetzt, wenn du Bilder
anwendest. Ja, ich finde schön ist ein
gutes Stichwort für eine Überleitung, um mal so bekannte
Beispiele zu nennen oder Frameworks und Sprachen, die auf
dieses Pattern, sage ich mal, darauf zurückgreifen.
Ja, und das sind ja oft schöne Implementierungen, also man
sieht das halt auch sehr oft im zum Beispiel bei Springboot gibt
es das viel. Du hast halt auch so so Bilder
Patterns in Lombok zum Beispiel, ich mein oder auch gerade wenn
ich jetzt so Calls mache, ne, also beispielsweise ich schreib
jetzt ich hab jetzt n frontend und möchte jetzt rest Calls
absenden und ich verwende verschiedene Bibliotheken dafür,
dann hast du ja auch oft sowas wie.
Set Header, Set body und du also kapselst du chainst halt diese
Aufrufe, um am Ende dein request Objekt sozusagen zu haben, was
du denn Absendest beispielsweise, das geht ja auch
in die Richtung, ja, dass das N Builder ist am Ende oder im
mobile App Bereich. Ja wir haben zum Beispiel ja
schon mit Flatter rumgespielt, ist auch ne ganz coole Sache und
Dart als Sprache setzt ja auch auf diese Konstrukte.
Ja gerade wenn du jetzt zum Beispiel deine UI Elemente
zusammenbaust, dann hast du auch oft.
Unter der Haube diese bilderpattern ich kann mich
erinnern, ne und da sieht man ja, dass es halt schon seine
Daseinsberechtigung hat. Ja, definitiv.
Also ich würde halt auch sagen, dass prinzipiell Bilderpattern
schon auch viel genutzt werden. Also das ist jetzt zum Beispiel
schon, auch weil wir jetzt beispielsweise Singleton auch
hatten würde ich würde ich sagen, dass es mehr
Bilderpattern und Bilderpatterns öfter eingesetzt werden als
Singletons auch. Aber dass sie jetzt auch nicht
exorbitant eingesetzt werden. Also es ist halt auch oft so,
dass ich mir manchmal denke, oh, ihr könnt n bilderpattern nehmen
und dann denke ich noch ein bisschen drüber nach und denke
mir dann auch gleichzeitig wieder oder kurz danach,
eigentlich brauche ich das auch nicht so, also ich finde es ist
jetzt nicht irgendwie inflationär gesät, dass man
einfach überall bilderpattern hat, aber es gibt halt gute
Möglichkeiten eben so n Bilderpattern einzusetzen und
dafür ist es halt eben aber auch wichtig zu wissen.
Es gibt ein Bilderpattern und wie verwende ich ein oder baue
ein Bilderpattern. Das ist halt in dem Fall, das
ist eigentlich genau der richtige Punkt zu sagen wann.
Wie, wo, was? Ja und du hast ja so schön
angefangen, magst du vielleicht zum Abschluss der Folge mal so
ein Fazit sehen? Wann würdest du sagen, da
verwende ich das Bilderpattern, da macht es Sinn.
Genau. Also wenn du halt viele
optionale Konfigurationsfelder hast beispielsweise, dann macht
das Sinn, wenn du generell viele.
Parameter hast, die du irgendwie in konstruktor reingeben
würdest, wenn du verschiedene Objektvarianten hast, wo du
sagst, OK, das ist aber immer dieses eine Objekt.
Es hat aber unterschiedliche Ausprägungen.
Du willst aber auf der anderen Seite auch nicht alles wieder in
was weiß ich wie viele Tiefen von Abstraktionen einbetten,
weil es vielleicht auch in dem Fall einfach nicht gut wäre.
Das ist halt immer sehr sehr. Also ich find da geht auch immer
n bisschen Erfahrung mit einher, so dieses Feingefühl zu sagen
wann macht es Sinn und wann nicht.
Auch wenn jetzt zum Beispiel, wenn du jetzt Objekte mit
rekursivem Aufbau hast oder so ne, also so n Dom beispielsweise
im Frontend ist so n schönes Beispiel dafür.
Und ja ansonsten. Gerade weil du es da drin
verkapseln kannst, dann halt auch ne.
Stimmt. Und was wir eben ja auch schon
meinten, wenn man jetzt irgendwie sauberen, lesbaren
Code haben möchte, ist halt n bilderpad dann schon ganz schön
ne. Also da, das ist halt einfach.
Ne gute Möglichkeit einfach ne schöne Lesbarkeit einfach von
diesem Code zu erzeugen, weil es einfach besser ist als zu sagen
ey ich erzeug jetzt hier, ich mach jetzt n konstruktor und hab
da 1000 Parameter, so hast du ja wie noch ne kleine Beschreibung
über diese Funktion, beispielsweise dass du siehst,
OK, das passiert jetzt, das passiert jetzt, das passiert
jetzt ne wann ich es jetzt zum Beispiel nicht einwenden würde
ist, wenn du kleine Objekte hast ne du hast vielleicht irgendwie
2 bis 3 Parameter oder am besten noch weniger so dann reicht n
einfacher konstruktor du weißt eigentlich relativ.
Schnell OK, was passiert hier überhaupt?
Oder du guckst einmal eben kurz da rein in den Konstruktor und
siehst OK, diese beiden Werte werden gesetzt, macht schon
Sinn, passt alles ne dann beispielsweise was du ja auch
meintest, Performance sensible Bereiche würde ich es auch nicht
unbedingt einsetzen, weil ne hattest du ja so schön erklärt,
muss jetzt nicht noch mal wiederholen und.
Ja, einmalige Objektinstanzen ohne Wiederverwendung.
Wenn du halt wirklich mal, sagen wir mal selten mal ne Instanz
irgendwie erzeugen musst, warum dann die ganzen Bilder dieses
diesen Overhead dazu bauen? Wenn du aber eigentlich gar
nicht, wenn das jetzt ne seltene, wenn das jetzt selten
instanziert wird, beispielsweise ne, weil wie gesagt es kommt
Komplexität obendrauf. Und man muss halt eben auch
genau gucken, okay was ist dann im Endeffekt valide und was
nicht und wie also wie gesagt, du bist frei in der Anwendung
von diesem Bilder Pattern und da muss man eben halt auch gucken
okay nimmt man es hin und sagt der oder der Programmierer die
Programmieren wird das schon verstehen oder man muss halt
eine Menge sozusagen abfangen vielleicht oder sehr viel Logik
einbauen. Ja, ich finde den letzten Punkt
halt auch wirklich gut. Zu sagen, wie oft brauche ich.
Eine Variante dieses Objekts davon, wie oft instanziiere ich
das, weil man muss auch sagen, diese Wahl des Patterns, ob ich
ein bilderpattern brauche, ist auch irgendwo kontextabhängig,
ne in welchem Rahmen programmiere ich gerade.
Es macht natürlich absolut Sinn, wie ich meinte, dass du ja in
verschiedenen Frameworks für Sprachen zum Beispiel so ein
HTTP client hast, der so ein Bilderpattern implementiert hat,
unter der Haube ne weil. Da ist der Kontext.
Ich muss alle Arten von Request irgendwie ermöglichen und
zusammenbauen können für den Anwender.
Das heißt ich hab ne enorme Vielfalt und möchte aber diese
Flexibilität sauber darstellen, das ist ja n ganz anderer
Kontext als zu sagen ich implementiere jetzt ein Call
weil ich hab jetzt nur einen Endpunkt den ich anspreche in
meiner Software und ich wir gehen mal davon aus wir
verwenden jetzt nicht dieses Framework mit den Bildern weil
dann würdest du dann logischerweise einfach das
nehmen da aber dann hast du es ja auch nicht implementiert.
Wenn ich es jetzt aber selbst implementiere, dann würde ich
doch nicht anfangen n Riesenkonstrukt als Bilder
Pattern aufzubauen für einen spezifischen Call oder
beispielsweise das Config Management.
So ne ich hab ich lad ne config, ja lädst du eine statisch am
Anfang, dann lad sie halt, dann musst du ja nicht dynamisch
irgendwie ne config zusammenbauen, also es ist halt
auch immer ne Frage des Kontexts am Ende das ist kann man auf
jeden Fall so als Take Home Message auch noch mal mitnehmen.
Ja, dann fabi, vielen Dank dafür auch für deine Zusammenfassung.
Am Ende hat mir mega Spaß gemacht, ich find das Pattern
auch ziemlich cool, es macht auch Spaß das mal umzusetzen,
also weil du hattest es vorhin schon gesagt, liebe Zuhörer,
liebe Zuhörer, probier es ruhig mal aus, wenn du noch nie mit
dem Pattern gearbeitet hast beziehungsweise es noch nie
selbst implementiert hast, weil um diese ganzen Fallstricke ja
und vor und Nachteile wirklich verstehen zu können, lohnt es
sich es auf jeden Fall mal zu implementieren und es ist
sprachenunabhängig ja also du kannst eigentlich in jeder
Sprache. Wenn es Objektorientiert ist,
sagen wir es mal so, das sollte es schon sein, abbilden, und das
ist halt wirklich eine coole Sache und lohnt sich auf jeden
Fall, um auch einfach mal das Verständnis dafür zu entwickeln.
Ansonsten lieber zuhören, lieber zuhören, falls du Fragen hast,
Hau raus, schreib uns, lass uns drüber quatschen, wenn du
Anmerkungen hast, Ergänzung, Fragen zum Buffet hast immer
raus damit, schreib uns die Mail, findest du in den
Shownotes. Essenstipps sag uns essenstipps
genau, sag uns auf jeden Fall, ob du das Pattern schon
verwendet hast, ob du es vielleicht indirekt verwendet
hast und jetzt weiß, dass das Pattern dahinter steckt, weil du
zum Beispiel mit Frameworks arbeitest.
So klassische Fälle hat jeder mal, dass man sich denkt, AH OK,
deswegen geht das so und. Und ansonsten auch noch mal der
Aufruf. Wenn dir der Podcast gefällt,
lass gerne ne Bewertung da, abonniere ihn, empfehle ihn
gerne weiter, das würde uns ungemein freuen und
weiterhelfen. Alle Links zu unseren
Plattformen in den Shownotes wie immer Schau auf unserem Discord
Server vorbei, wir sind mittlerweile so ne unglaublich
coole Truppe da Grüße gehen raus an alle und ansonsten würde ich
sagen haben wir uns nächste Woche alle wieder ne.
Und bis dahin habt ne schöne Zeit deine Coding Bodys.
Gemeinsam besser.