Latest / Coding Buddies | Tech & Dev-Mindset / #126 Design Patterns 4 – Builder statt Chaos

Transcript

#126 Design Patterns 4 – Builder statt Chaos · Coding Buddies | Tech & Dev-Mindset

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