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.