A 5 leichter schliff auf 3 und denkst dir so ey.
Was alter, Oh mein Gott, oh mein Gott, bitte entfernen Sie nicht
Coding Buddies Dein Podcast rund um Softwareentwicklung und
aktueller Tech News. Herzlich Willkommen.
Halli Hallo und herzlich Willkommen zur neuen Folge des
Coding Bodys Podcasts. Schön, dass du wieder
eingeschaltet hast. Und wie soll es anders sein,
deine Gastgeber wie immer und jetzt auch schon seit einer
ganzen Weile meine Wenigkeit, der Tino und der fantastische
Fabi, der mir wie immer hier gegenüber sitzt und ich ihn
begrüßen mag, er grinst, er hat Bock, er ist bereit fabi was
geht ab? Einen wunderschönen guten Tag,
Tino. Einen wunderschönen guten Tag.
Geht es? Wie geht es dir?
Mir mir geht es gut, das Wetter schön.
Das ist schön. Ich hab das schon mal ne
langsame. Voraussetzung Ja, Gefühl
langsamer Sommer hast du, hast du dir was vorgenommen.
Diesen Sommer geht es irgendwo hin, geht es irgendwie cool in
den Urlaub. Ne, ich hab noch gar nicht so
viel geplant, ich bin aber sehr spontan im Buch, auch sowas
meistens sehr spontan, hab noch keinen Plan, ne kann ich kann
ich. Kann ich nichts berichten jetzt
so ne coole Urlaubsstory oder so, da ist noch nichts geplant
da. Wünsch ich dir auf jeden Fall
dir erzählen, dass du was Schönes findest.
Ja, klar. Ja, ich, ich glaube, pass auf,
wir hatten das glaub ich mal in irgendeiner.
Es ist jetzt auch schon n paar Jahre her, also man kann ja
jetzt glaub ich schon fast sagen 2 Jahre weil so lange machen wir
schon n Podcast ungefähr n bisschen mehr.
Ist heftig. Ja, und ich hab irgendwann mal
gesurft. Habe ich auch berichtet in in
der Podcast Folge und das mache ich diesen Sommer noch mal.
Hat mir so gefallen, dass ich Bock drauf hatte noch mal surfen
zu gehen. Das heißt im August werde ich
auf jeden Fall noch mal eine Runde surfen.
Dann haben wir die gleiche Podcast Folge einfach noch mal
raus. Genau, einfach.
Das Surfen, Salz und Def Offs oder wie soll ich das?
Stimmt ja, kann ich auf jeden. Fall nur ja, Wellen surfen.
Ist auch ne coole Sache, ist auch ne coole Sache, das glaub
ich dir sofort. Ich bin ja eher noch beim
Wintersport, aber ich denk mal surfen wird auch noch mal auf
meiner Agenda sein, unbedingt ansonsten bis wir denn zu der
Surffolge kommen, wollen wir ja heute mal quasi ein neues Thema
anfangen, wir haben ja immer so kleine Podcast folgenreihen sagt
man glaub ich nennt man so und es ist Zeit mal wieder für ne
neue Wir haben ja auch schon so n Paar abgeschlossen, wir hatten
ja zum Beispiel die Clean Code Reihe.
Und haben uns gedacht, Na, lass uns doch mal ne Reihe machen zu
so richtigen Basics. Ja, also so wirklich Themen, die
gerade für Einsteiger noch sehr relevant sind und für
Fortgeschrittene immer noch relevant sein sollten, auch
gerade so hinsichtlich Auffrischung noch mal da n
bisschen drüber nachdenken. Ja, so Back to the roots ja
dementsprechend. Haben wir doch n ganz, ganz
cooles Thema mitgebracht, oder? Fabi hau doch mal raus.
Das Thema ist Software Design Patterns, also ich mein.
Kurz, kurz, sag kurz, jetzt kannst du was anderes.
Ich meine, man hat das sicherlich schon mal gehört,
zumindestens sowas wie Factory Pattern, singleten, Observer,
Pattern oder was auch immer. Also es gibt ja einige von
diesen Patterns und. Wir wollen einfach jetzt mal ne
Reihe starten. Ne, heute geht es erstmal so n
bisschen um die Einleitungsfolge um dann sozusagen immer mal
wieder regelmäßig ein bestimmtes Pad an uns rauszunehmen.
Vielleicht wären es auch 2 pro Folge, gucken wir mal und die n
bisschen durchzusprechen ne um einfach mal zu gucken OK ne was
ist das für n pad dann was wird da eigentlich ne was wird damit
gemacht, warum braucht man das überhaupt, warum nutzt man das
eigentlich ne und ich meine? Selbst wenn man Patterns
vielleicht noch gar nicht so richtig kennt, ist es ja auch
so, dass man vielleicht unterbewusst beziehungsweise
nicht unterbewusst, sondern unbewusst dieses Pattern
vielleicht schon nutzt. Ne, also ich hab das glaub ich
selber auch schon mal gehabt, dass ich mir dachte, so oh, ich
brauch jetzt zum Beispiel. Ne Klasse, die nur irgendwie
einmal existiert und hab dann irgendwas zurecht gefriemelt und
dacht mir so Oh guck mal, ist n Singleton so ne sowas aber
besprechen wir alles noch mal im Einzelnen ja.
Ich glaube, du hast ja allein schon den Fall, wenn du sag ich
mal Frameworks verwendest, Lips verwendest oder hast selbst
Sprachen an sich, die ja unter der Haube auch.
Auf Design Pattern zurückgreifen, ne, dass du halt
sagst, OK, warum muss ich jetzt das so und so aufrufen unter OK
was gehen da für Parameter rein und unter der Haube sitzen da ja
auch wieder Design pattern. Warum ist es so, warum muss ich
das überhaupt so aufrufen? Ja und deswegen ist das so n
sehr basic Thema aber immer cool da noch mal drüber nachzudenken.
Ja, es ist ja auch immer aktuell, weil irgendwie.
Kommt man eigentlich, wenn man im Alltag programmiert, egal wo
dran, man programmiert eigentlich immer wieder an
irgendwie Punkte wo man sagt, OK, dies oder jenes Pattern
macht schon Sinn das jetzt einzusetzen und dann hilft es
halt auch manchmal darüber Bescheid zu wissen, was es
überhaupt für Patterns gibt, wann man die vielleicht benutzt,
damit man einfach in der Lage ist, in seinem Repertoire
einfach darauf zurückzugreifen und nicht erst weiß, nicht ewig
darüber zu überlegen, weil es macht ja auch einfach Sinn.
Und in der Folge jetzt wollen wir noch nicht speziell.
Über. Bestimmtes Pattern reden,
sondern erst mal klären, was überhaupt Design Patterns genau
sind, warum man sie halt kennen sollte und halt einfach mal
gucken, welche schon mal ein bisschen anreißen, was wir
vielleicht für Patterns in der neuen Reihe, die wir jetzt
anfangen mit dieser Auftakt Folge besprechen wollen.
Genau und Liebe zu Liebe zu. Falls du dir denkst, so geiles
Thema, ich habe richtig Bock auf die Reihe und vielleicht
allgemein unseren Podcast abfeierst und.
Schau doch mal in die Shownotes, da findest du n Link, falls du
Bock hast uns n bisschen zu supporten, da ist n spenden Link
dieser Aufruf ganz kurz an dieser Stelle bevor wir jetzt
los starten. Wir würden uns mega freuen das
supported uns extrem und schon mal vielen Dank dafür und jetzt
wie Let's Go lass die Reihe starten wir.
Brauchen jetzt so ne Tröte. Genau.
Also wir können ja erstmal
anfangen, was eigentlich so Software Design pattern
eigentlich was es ist ne. Ich find man kann das ja, du
weißt wie ich es, wie ich es gerne handhabe, am besten mit
Analogien erklären und ich weiß gar nicht, ich glaub in unserer
allerersten Folge hattest du mich mal gefragt, wie du oder
was ich an der Softwareentwicklung so mag und
ich hab da so ne Analogie lego genommen und die würde ich jetzt
noch mal ähnlich verwenden, weil wenn du sagst du hast Design
pattern ne und du und das ist so wie wenn man sagt man baut mit
Lego etwas. Und du kannst ja mit Lego alles
mögliche bauen, ne. Und wenn du jetzt zum Beispiel
aber sagst, du willst keine Ahnung n Auto bauen, dann
braucht das irgendwie 4 Räder und irgendwie sag ich mal ne
Karosserie und damit du nicht aber jedes Mal überlegen musst,
sag mal wie bau ich denn jetzt diese Karosserie, gibt es dann
vielleicht ich nenn es mal so ne Anleitung wo du bestimmte
gängige oder bewährte Bauschritte drin hast um halt
eben sowas dann einfach schnell noch mal bauen zu können, ohne
dass du jedes Mal überlegen musst.
Ha. Wieviel Räder waren denn das
noch mal im Auto 4? 5. 20 weißt du, sind ja fragen,
die einem ständig aufkommen. Dann beim Legoboard.
Ich frag mich auch grad welches Auto 20 Räder hat, aber es gibt
bestimmt welche. Nee, aber.
Also in der Analogie kannst du es halt so sehen.
Ne LEGO ist halt dann der Code und diese Anleitung von dir ich
gesprochen sind dann im Endeffekt die Designpad dann
nachdem man dann sozusagen basteln kann ne.
Also es sind halt ja ich sag mal.
So. Es ist nicht etwas, wo du sagst,
so ist es copy paste und fertig für das Problem, sondern es ist
im Endeffekt etwas ja wo du dich es ist n Konzept so das kann man
sagen. N wiederverwendbares Konzept und
gerade so bei LEGO. Wenn du zum Beispiel wie du
schon meinst, so Autos ne, dann wirst du halt zum Beispiel dir
denken Hey aber warte mal n Auto ist ja immer gleich aufgebaut,
dann kann ich ja schon mit diesem Konzept immer diese
Grundstruktur bauen und dann halt nur noch.
Quasi adaptieren wie genau das Auto da noch mal aussehen soll.
Aber der Grundaufbau ist der gleiche und da sind wir auch
schon bei dem ersten Pattern, das geht nämlich ganz stark in
die Factory Pattern Richtung. Was werden wir auf jeden Fall
mal hier in der Reihe beleuchten, aber da sieht man
halt schon, es gibt halt Konzepte die man immer wieder
verwenden kann und das ist nicht nur bei Autos so, bei Häusern
also wir sind immer noch in der Legowelt ne wenn du anfängst dir
so ne kleine lego Stadt zu bauen wirst du immer wieder zu dem
Punkt kommen zu sagen. Warte mal so was ähnliches hatte
ich schon mal. Wie habe ich denn das gemacht,
als habe ich so eine so eine generelle Lösung dafür, wie ich
das angehen kann. Halt ne ich finde die Analogie
auch mega cool, eine die auch so rumgeistert weil sie halt auch
sehr treffend ist ist so eine typische Bauanleitung, ne also
sagen wir mal so was wieso eine Ikea bauanleitung?
Ikea ist ein super Beispiel für ne wer schon mal irgendwie da
eine Küche oder so aufgebaut hat dann erstmal ich fühle das das
ist echt Scheiße. Mach das lieber nicht.
Aber du hast ja am Ende genau solche Sachen wie Hey, so ein
Korpus ist immer gleich. Ja, du machst vielleicht eine
andere Tür dran, am Ende vielleicht ein anderer Griffe,
aber du hast halt eine Anleitung, die dir erstmal sagt,
so und so machst du erstmal einen Korpus und damit fängst du
jetzt an deine Küche aufzubauen. Ja, und genauso ist es in der
Softwarewelt dann am Ende auch und ich finde das sind auf jeden
Fall sehr treffende Analogien. Ja, vor allem die funktionieren
halt einfach in. Also ich würde mal sagen.
Je nach Anwendungsfall und je nach Pattern, was du vielleicht
gerade gebrauchen kannst, funktionieren die halt einfach
irgendwie universell in vielen Projekten und in vielen
Kontexten und das ist halt das Schöne.
Das heißt, wenn du einmal das Konzept oder diese diese
Strategie verstanden hast, wie Code sozusagen in diesem Pattern
eigentlich arbeitet oder was da eigentlich hinter steckt oder
wofür man das verwendet, dann ist es natürlich einfach
sinnvoll und hilft dir dann im weiteren, dein Code einfach zu
verbessern. Und deswegen ist es nicht
schlecht. Also wenn du jetzt mal als
Beispiel ne, du brauchst ne ne Möglichkeit wie mehrere Teile in
der Anwendung zum Beispiel benachrichtigt werden, also zum
Beispiel du hast irgendwie n System und musst halt keine
Ahnung sagen wir mal teilsystem a, teilsystem b und Teilsystem
c, musst du irgendwie benachrichtigen ne und du sagst
ja so ah was mach ich denn jetzt?
Da gibt es vielleicht irgendwie du kannst dir was überlegen, du
kannst dir irgendwie ne ne Strategie zusammenbasteln wie
man irgendwie das alles hinkriegt.
Aber um zum Beispiel, dass also zum Beispiel über die GUI ne,
also du hast so ne GUI, klickst da irgendwo drauf und dann
werden halt alle diese Teilsysteme benachrichtigt,
kannst du halt zum Beispiel mit zum Observer Pattern
beispielsweise machen. Nur mal nur mal irgendein
Beispiel zu nennen, dass man einfach mal jetzt in der
Softwarewelt sozusagen diese Analogie jetzt umsetzen und
sagt, OK, es gibt ein eine Lösungsstrategie und diese
lösungsstrategie kann man dann anwenden und das ist natürlich
etwas abstraktes, Allgemeines, was du dann auf den konkreten
Fall anwendest. Genau das ist nicht der Punkt,
dass egal was man am Ende entwickelt, was für ein Produkt
das ist, in welcher Sparte das ist.
Die Softwareentwicklung kommt oft an gleiche Probleme, die
schon gelöst wurden und dann kannst du halt so Strategien
wieder verwenden, zum Beispiel so was wie.
Hey, ich hab irgendwelche wie du gerade meintest.
Ne Komponenten die müssen informiert werden wenn in einer
anderen Komponente sich was ändert, also wie Krieg ich das
hin? Ja die müssen jetzt irgendwie
darauf lauschen, die müssen irgendwie mitkriegen wenn sich
da was ändert, weil du jetzt zum Beispiel so n Observer Pattern
ansprichst und das ist ja genau der Punkt dieses Grundproblem,
ja die. Hast du immer wieder, ob du
jetzt keine Ahnung frontend machst oder keine Ahnung
wirklich Desktop Applications selbst überall, egal in welcher
Sparte, in welcher Branche, wie auch immer, sowas kommt ja immer
wieder und da gibt es halt Lösungen, die haben sich
durchgesetzt, die sind durchdacht sag ich mal und es
ist auf jeden Fall super hilfreich sich die mal
anzuschauen zu verinnerlichen weil es einfach.
Im Prinzip deine Denkweise und auch dein ja, dein dein dein
Toolset erweitert ne, weil du halt zu diesen Problemen kommst
und dir denkst, ha warte, da kann ich das und das Pattern
nehmen, das wird da gut, das hat sich bewährt.
Ja, das ist ja wirklich so, das hat sich bewährt.
Ja, ob es immer der richtige Weg ist?
Klar, das ist irgendwann auch fallspezifisch ne.
Es gibt auch Fälle wo du sagst, ja vielleicht doch nicht das
Patternehmen, obwohl es vielleicht letzte mal ne sehr
gute Sache war, aber in dem Fall ne ist natürlich auch immer
spezifisch, aber du hast auf jeden Fall ne Anlaufstelle.
Und da hilft. Auch das Bild rumgeisters ne,
was ja so dieses klassische Antipattern war wär ich mach
erstmal es funktioniert jetzt kommt noch was rein oh er
funktioniert immer noch, irgendwann gar keine Struktur,
keine Strategie. Ich bin am Arsch.
Sowas, aber dafür hilft es natürlich auch, dass man mehrere
verschiedene kennt, also mehrere Design Pattern, ne, dass man
jetzt nicht immer nur auf 1 zurückgreift, sondern vielleicht
auch ein Repertoire hat und das wollen wir auch ein bisschen mit
der Reihe schaffen. Ich finde es gut, dass du
Antipattern angesprochen hast. Ich finde das sollte auch mal
eine Folge werden, dass wir einfach auch mal darüber reden,
was eigentlich antipattern sind, weil das ist nämlich eigentlich
im Endeffekt genau das Gegenteil von dem Design pattern, weil
Design pattern also. Wenn wir jetzt überlegen, warum
die eigentlich wichtig sind, ne, warum gibt es dir eigentlich was
was? Wobei helfen die denn überhaupt?
Ne? Also allein was mir als Erstes
einfällt ist, dass du zum Beispiel einfach ne ne super
Erweiterbarkeit hast und ne höhere Flexibilität in deinem
Code. Ne wenn du jetzt zum Beispiel
sagst, du hast jetzt n infactory pattern, ne, dann dann kannst du
zum Beispiel. Ne, wie der Name schon sagt
irgendwie. Du hast ne Factory, du kannst da
verschiedene Sachen draus bauen. Also du kannst jetzt zum
Beispiel sagen, OK ich bau jetzt n Auto aber ich kann zum
Beispiel vielleicht aber auch n anderes Modell von einem Auto
bauen, ne wie auch immer, aber weil wir vorhin bei Auto waren
aber du hast halt eine Fabrik die dir verschiedene Variationen
einer Instanz ausspucken kann, die aber irgendwo sagen wir mal
n Kern haben n gleichen Kern und n Antipattern zum Beispiel und
das hilft halt einfach weil wenn du jetzt zum Beispiel n Neues.
Keine Ahnung. N neues Modell reinbringst was
irgendwie rauskommen soll, was aber im im Grunde ne im im Kern
das Gleiche ist. Dann ist es einfach schön, dass
man das Ganze einfach erweitern kann.
Ne, also du hast halt, musst nicht mehr viel machen und
kannst sozusagen aus dieser Fabrik relativ schnell wieder
was ähnliches rauszaubern und das ist ja das schöne und n
Antipattern zum Beispiel weil das, darauf wollte ich gerade
noch mal hinaus, das ist halt etwas.
Was eigentlich genau das Gegenteilige bewirkt, also
sozusagen die Erweiterbarkeit und Flexibilität, wenn wir jetzt
bei dem Beispiel bleiben, einfach einschränken, ne.
Und ja, du hast halt den Punkt ne, wenn wenn man das
Autobeispiel nimmt. Du kannst ein Modell
reinbringen, du kannst 2 reinbringen 34 das mag alles
noch gehen ne dann sagst du ja OK ich definier zum Beispiel
jedes Mal wieder, dass n Auto 4 reifen hat, ne 4 Räder, 2 Achsen
wie auch immer, alles was man so definieren könnte dann auch auf
softwareseite ne. Das mach ich halt 34 mal.
Aber wenn ich dann irgendwann ne riesen Palette hab es quasi ne
große Fabrik sag ich mal ja hab ich Bock das alles jedes Mal
noch mal neu zu definieren oder hab ich im Kern nen gleichen
Aufbau und nur die Farbe ändert sich oder keine Ahnung die
Leistung der Motor was man immer denn auch variieren möchte in
seiner Software und da merkt man halt schon so hey ja warte mal
es macht absolut Sinn da irgendwie so ne gemeinsame.
So n kleinsten gemeinsamen Teiler zu finden und genau dafür
sind dann halt auch so Pattern da, damit dein Code nicht
komplett auswuchert ne, dass du gar nicht mehr weißt wo vorne
und hinten ist, sondern erst skalierbar, er ist Wartbar ist
ne, dass er verständlich ist und da gibt es halt richtig richtig
gute Design patterns. Die man auch wirklich regelmäßig
verwendet. Und es ist auch irgendwo ne
stilistische Frage. Das heißt, es gibt Leute die
fahren total auf das eine Pattern an ab wo andere das gar
nicht verwenden, dann gibt es halt auch immer so 2 Lager.
Ja wie kannst du das nehmen, das ist total schlecht und die
anderen sagen ohne das kann ich gar nicht leben so.
Also das ist auch immer so ne Mindset frage am Ende und
deswegen würde ich sagen, also wir werden das ja so machen,
dass wir die hier objektiv ganz neutral mit so vor und
Nachteilen beleuchten, die wir da drin sehen.
Also Neutralität im Sinne von wie wir das sehen aber nicht
bewerten, ob wir das gut oder schlecht finden, weil ich finde
jedes hat am Ende seinen an Anwendungsfall sag ich mal auf
jeden Fall und es spielt halt auch immer viel Erfahrung am
Ende mit rein und deswegen gerade liebe Zuhörer liebe
Zuhörer, wenn du vielleicht am Anfang deiner
Softwareentwicklungskarriere stehst schau dir ruhig mal
verschiedene an und nimm dir mal 1 und bau mal verschiedene
kleine Sachen damit und probier dich damit aus.
Versuche herauszufinden, was gefällt dir daran, was gefällt
dir daran nicht, welche Grenzen siehst du und welche Vorteile
und ich finde mit so kleinen Beispielen und wenn wir quasi in
den einzelnen Folgen auf die Patterns eingehen, können wir
auch Beispiele nennen, die man vielleicht so ein bisschen
nachcoden kann, merkt man erstmal eher, doch das ist so
wie cool, das hilft mir ja. Was ich zum Beispiel auch finde,
ist, dass es natürlich auch hilft zu sagen, OK, wenn du
beispielsweise diese Begriffe, wenn die also wenn dir diese
Patterns n Begriff sind und du vielleicht auch in, sagen wir
mal im Team arbeitest oder so, dann hast du natürlich auch
einfach dieses Vokabular mit dem, was dahinter steckt, halt
eben auch direkt drin. Also wenn jetzt zum Beispiel
jemand sagt, soeben, da würde ich doch zum Beispiel am besten
das verwenden und du denkst dir so coole Sache, weiß ich gerade
nicht, was das ist. Und ich weiß ja auch, wie das
ist. Also ich hab das selber auch
schon n paar mal gehabt, so dass man sich dann zwar denkt, Oh,
das muss ich mal nachgucken, aber im Endeffekt guckt man es
ja doch nicht nach, weil man ist ja auch meistens mit anderen
Sachen beschäftigt, ne? Ne, das ist so auch so ne kleine
Analogie. Ich stell mir das manchmal immer
so vor, weil du meinst so so Vokabular ne, stell dir vor du
bist jetzt noch mal so im handwerklichen Bereich unterwegs
ne und kommst so neu in ne Firma und hast so n Projekt und bist
zum Beispiel jetzt vielleicht n Lehrling oder so ne.
Und wie es nervt ja am Anfang so angenommen du, du trägst den
großen, sag schon Werkzeugkoffer ne immer hinterher hinter dem
Meister und er sagt Ja gib mir mal das und das hier komm wir
brauchen Ah siehst du den Fall wir brauchen jetzt das und das
und du wühlst da drin rum weißt gar nicht was du rausnehmen
sollst. Gibst du ihm irgendwas in der
Hoffnung dass es stimmt so ne und das ist ja im Prinzip auch
ne Analogie dafür, wenn man sich mit diesen Themen
auseinandersetzt und dann in ein Team reinkommt, jemand sagt EY
wir haben hier n Problem. Vielleicht können wir das so und
so lösen und du kennst das Pattern und hast so quasi ne
strategische Übersicht wie es hier angewandt wird und ob das
Sinn macht oder nicht. Ob das Sinn macht oder nicht,
sind nachher Erfahrungswerte ganz klar ne ne.
Also wenn ich so an an die letzten oder so einige Jahre
mittlerweile zurückdenke, wo auch im Studium wo wir so
Patterns kennengelernt haben, dachte ich mir ja ich bin bereit
für die Coding Welt ich kann dieses Pattern, ich werde alles
mit diesem Pattern lösen und dann.
Also exzessiv genutzt, obwohl es gar nicht sinnvoll war, am Ende
oder vielleicht echt Nachteile mit sich gebracht hat.
Deswegen ist immer so pro Contra und Fall abhängig, aber es ist
halt einfach wichtig diese zu kennen.
Ja, ich finde deine Analogie muss ich gerade daran denken,
dass ich letztens, weil ich bei meiner Zahnärztin und kennst du
das, wenn du sitzt, da da, dann wird dein deine Zähne werden so
durchgecheckt und dann so C 3 bis 8 sind OKA 5 leichter
schliff auf 3 und du denkst dir so ey.
Was alter, Oh. Mein Gott, Oh mein Gott, bitte
entfernen Sie nicht. Und jetzt stell dir mal vor,
dass du diese Vokabeln als zum Beispiel weiß, nicht hier, wie
heißt das der Supporter hier zahnarzthelfer, wenn du das da
nicht drauf hast, dieses. Vokabular ne so alles.
Klar weiß ich auch nicht. So ja OK, ich sag mal wir bohren
da genau. Da musst du dran denken.
Aber du meintest ja eben, wir wollen das natürlich objektiv,
dann die einzelnen Pattern betrachten und das finde ich
auch sehr gut. Wir können aber trotzdem finde
ich auch immer noch ein bisschen dazu sagen, ob wir die zum
Beispiel auch oft verwenden oder nicht, weil ich weiß selber,
dass ich zum Beispiel bestimmte Pattern oft auch gerne verwende,
einfach auch, weil man es schon oft so oft gemacht hat und
andere verwendet man vielleicht nicht so oft, aber das sind
immer finde ich auch genau die Punkte, weil es kommt immer
darauf an. Auch wie oft, was du eigentlich
auch meintest, ne wieviel Erfahrung man damit schon
gesammelt hat, weil es ist am Ende ja auch irgendwie ne Sache
von wie gut kann ich dieses Tool benutzen?
Ne also du wirst dich ja genauso hinstellen und sagen ey wenn ich
zum Beispiel IDI 1 verwende, immer zum Beispiel von Jet
Brains oder so und aber auf der anderen Seite irgendwie n
anderer IDI nicht so oft verwende.
Dann nimmst du natürlich eigentlich lieber das, was du
schon gerne, also was du öfter verwendest, ne.
Aber genau dafür ist es natürlich auch da, dass man auch
so seinen Horizont erweitern kann und sagen kann, EY Pass
auf, es gibt ja noch die und die Patterns und meistens gibt es
auch vielleicht wirklich für n bestimmten Anwendungsfall.
Hattest du vorhin glaub ich auch gesagt mehrere Patterns die man
einfach verwenden kann, ne ist einfach gut und ich glaub da
kann man selber auch noch. Also selbst wir können auch was
dabei lernen. Das wollte ich gerade sagen.
Ich hab halt auch, als du die Reihe vorgeschlagen hattest, war
das auch so mein erster Gedanke, dass ich halt wirklich Bock
drauf hab, weil es gibt viele Patterns und es gibt viele, die
ich ewig nicht verwendet hab, weil du ja wie du gerade so
meintest. Man kommt halt in seinen Modus,
ne in seinen Stil so und guckt manchmal nicht mehr nach links
und rechts, gerade wenn man projektgetrieben ist.
Ne vielleicht Deadlines hat, dass man sagt ja nee ich löse es
so. Wie es mir jetzt im Sinn kommt.
Vielleicht gibt es andere charmante Lösungen, vielleicht
auch bessere, die ich jetzt aber einfach gerade nicht auf dem
Schirm, aber ich mach jetzt so mit meinem Stil das und da, das
ist jetzt weder gut noch schlecht bewertet, ne, aber es
ist einfach Fakt, dass man irgendwie so seinen Coding Stil
hat und deswegen hab ich so Bock auf die Reihe, weil wir uns ja
damit zwangsläufig noch mal alle Patterns angucken und ich hab
auch Bock alle noch mal so n bisschen Beispiele zu coden.
Einfach das aufzufrischen und deswegen auch die der Appell am
Anfang gerade auch an fortgeschrittene Coder oder
Coderin oder auch vielleicht seniorentwicklerin, die halt
mega viel Erfahrung haben, einfach noch mal n step
zurückgehen und sich noch mal auf die Basics besinnen und sich
das alles noch mal angucken. Vielleicht.
Entdeckt auf jeden Fall Sinn. Genau.
Vielleicht entdeckt man noch mal was Schönes, was man vielleicht
was, was vielleicht auch in Vergessenheit geraten ist.
Ne, manchmal denkt man sich ja auch so ne wie du meinst du bist
im Modus und hast es dann vielleicht, du hattest es mal
verwendet, hast es aber für. Völlig verdrängt und denkst dir
wieder so, guck mal, das ist ja auch geil, aber Fakt ist es auf
jeden Fall, dass diese Design Pattern, die sind halt warum
sind die wichtig, weil sie am Ende eigentlich dafür im Großen
und Ganzen kann man ja zusammenfassend sagen, zur
Verbesserung der Codequalität einfach beitragen, aber wie du
schon meinst, es gibt sehr sehr viele Arten von Pattern, es gibt
ja glaube ich so verschiedene, also wir können das ja auch so
Kategorien mal einordnen, was es da so gibt.
Und vielleicht auch mal schon mal n Paar ansprechen.
Also wir hatten ja schon jetzt n Paar gesagt, die wir halt auch
jetzt definitiv auch mal in der in der Reihe sicherlich
besprechen werden, was was haben wir denn da so für Kategorien?
Nee, also ich glaub eine der größten ist so alles was
Richtung Erzeugung geht oder also erzeugungsmuster ne also.
Dass du im Prinzip ja. Wir hatten zum Beispiel das
Factory Pattern genannt, du hattest glaub ich schon
Singleton erwähnt. Bilder pattern find ich halt
auch ziemlich cool, würde da auch reinspielen und das ist
halt alles so, wenn ich zum Beispiel Objekte von Klassen
erzeugen möchte, ne, also Instanzen.
Da spielen die halt rein, dass da halt das ganze strategisch
nach einem gewissen Design Pattern abläuft, oder zum
Beispiel beim Single hast du ja schon gesagt, es nur einmal
passieren kann. Entweder habe ich keins oder 1
ja solche Sachen dann strukturmuster gibt es noch, da
fällt mir. Direkt, direkt und ich überlege
das Adapterpad dann zum Beispiel ne, also wenn ich sag ich mal 2
ich hab a und b und die können eigentlich nicht direkt
miteinander kommunizieren sag ich mal oder die greifen nicht
aneinander ne so richtig wie man sich das auch bei.
Bei verschiedenen Kabeln vorstellt ne, also so n so NUSBC
Adapter zum Beispiel weißt du, dass du sagst ey OK, ich hab
jetzt a, muss aber auf C kommen, jetzt nehm ich n Adapter der von
A auf C geht und dann passt das. Genau das ist die perfekte
Analogie schon wieder so OK. Ein Adapter patter du nimmst zum
Beispiel einen USBC Adapter. Ja, ja, weil der Name steckt da
schon drin, aber ich mein, da kann man sich das direkt
vorstellen. Ne, also du hast wie gesagt 2
Sachen die eigentlich nicht zusammenpassen und ich kann
jetzt mit einem gewissen Pattern dafür sorgen, dass ich die also
wie sagt man bitte? Verbinde verbinde ich find zum
Beispiel Proxy, fällt mir da auch noch ein.
Ich find Proxy klingt immer so sehr, wieso sagen wir mal außer
Internetkommunikation ne. So hast du mal dein Proxy
gecheckt, so ne aber im Proxy an sich ist ja am Ende auch wie
gesagt, das ist ja ein ein Lösungs oder ein Muster was man
verwenden kann und nicht nur unbedingt in der
Softwareentwicklung, sondern vielleicht auch irgendwie zum
Beispiel dann eher noch im Hardwarebereich.
Ne, also das kannst du ja da auch verwenden.
Also es ist halt immer wenn es jetzt.
Da also es ist natürlich schon im Internet, also im im im
Softwarebereich irgendwo, aber es ist so, ich würd sagen, das
ist so vielleicht so n bisschen nicht mehr ganz ausschließlich
Software kann kann jetzt jeder einordnen wie man will, aber für
mich ist Proxy. Also wenn ich jetzt an Internet
Proxy denke, irgendwie weiß ich nicht, das ist sowas, das
programmierst du nicht, sondern das konfigurierst du weißt was
ich meine. Ja, du bist jetzt ja OK auf
Server Seite. Ja, quasi.
Nee, aber deswegen. Aber es ist am Ende ist es ja
auch ein Designpattern in der Softwareentwicklung, was man
verwenden kann zum also unter Strukturmuster was da drunter
fällt, ne. Und dann?
Gibt es ja noch so Verhaltensmuster zum Beispiel.
Ja, da hast du ja glaube ich das Observer schon genannt.
Ne genau klassisches Beispiel, wenn ich halt irgendwie auf
etwas. Lausche oder ja Observer.
Ich beobachte n Verhalten von einer anderen Komponente und auf
Ereignis A möchte ich informiert werden oder ich möchte
mitkriegen, dass ein Ereignis auftritt, damit ich selbst drauf
reagieren kann, so n klassischer Anwendungsfall, ne.
Und dann würde ich sagen, also das sind jetzt so die 3
Kategorien, die ich auch. So wirklich.
Ich sag mal bei der Software Verorte bei der
Softwareentwicklung. Im weiteren Sinne gibt es
vielleicht auch noch so Architekturmuster.
Haben natürlich auch was mit Software zu tun, aber auf einem,
ich würde mal sagen auf einer anderen Ebene und deswegen würde
ich architekturmuster jetzt nicht in das in diese Reihe mit
Reinzählen, weil wir ja auch selber schon mal überlegt
hatten, dass wir vielleicht auch noch ne andere Reihe irgendwann
in Zukunft machen, wo es dann wirklich um Architektur und
Architekturentscheidungen von Software geht.
Ja, da auch gerne ne Nachricht an uns, wenn da Interesse
besteht, dass wir diese Reihe machen, dann werden wir das
natürlich auch sehr gerne tun, aber ja, ich weiß was du meinst.
Also du meinst jetzt zum Beispiel so hab ich ne kleinen
Server Anwendung, wär ja auch so ne Designentscheidung
grundsätzlich in meinem Projekt hab ich Microservices, manche
Frameworks die einfach auch sagen Hey pass auf das ist jetzt
NMVVM Pattern was du hier verwendest oder MVC.
Das sind ja alles auch Design Patterns, die aber irgendwo
übergeordnet, also nicht n Teil von deinem Code sind sozusagen,
sondern eine Architekturentscheidung deines
Deiner Software sind am Ende. Ja, ich find das ist natürlich,
also da kann man auf jeden Fall drüber diskutieren, aber
irgendwie würde ich es glaube ich auch, gerade weil wir auch
überlegt hatten, auch so in Sachen Clean Architecture, wie
gesagt. Wenn es da auch Interesse gibt,
auf jeden Fall uns gerne schreiben, aber dass wir da
vielleicht auch noch mal irgendwie ne Reihe drüber machen
und deswegen würde ich das glaube ich eher da verorten als
jetzt in unserer Design Pattern Reihe.
Genau ja. Ja, dann würde ich sagen, lasst
uns noch am Ende, wir wollten ja wie gesagt ne einführungsfolge
machen, das heißt gar nicht so lange heute aber noch mal kurz n
Aufbau gehen, wie wird das aussehen?
Also das ganze Stelle ich mir jetzt persönlich so vor,
korrigiere mich. Dass wir halt so gewisse Fragen
beantworten wollen. Zu dem Pattern ne und natürlich
auch irgendwie nen Mehrwert generieren wollen, was so Take
Home Messages zu diesen einzelnen Patterns sind.
Ne also zum Beispiel ganz klar, wofür verwende ich überhaupt das
Pattern XY, was gerade besprochen wird, also was löst
das für n Problem? Wie sieht n typisches
Codebeispiel aus? Hatte ich ja vorhin gesagt, das
sollten wir auf jeden Fall uns hinter die Ohren schreiben, dass
wir da was mitgeben und in welchen Situationen ist es halt
auch besonders nützlich dann oder halt nicht geeignet.
Ja, also ist ja mal n für und wider.
Gibt es Alternativen? Zum Beispiel?
Ja, guter Punkt. Manchmal hast du ja auch
Fallstricke, weil ich kenn das zum Beispiel auch, dass du
sagst, ich nehm jetzt so n Pattern und dann ist dieses
Pattern, wenn es zum Beispiel nicht wirklich geeignet ist.
Machst du dir das Leben damit eigentlich eher schwer, als dass
es irgendwie hilft? Und das sind manchmal auch so
Fallstricke, weil ich kenn das zum Beispiel weiß nicht, ich
wollte irgendwie auch mal n Bilderpetter nutzen und dachte
mir, so weißt du so halt, dachte ich mir so, das wär irgendwie
cool und irgendwie hab ich dann so in der ganzen Programmierung
dacht ich mir so ey, weißt du n bilderpetter macht dir irgendwie
gar keinen Sinn. Also.
Kommt halt auch dahin, dass man dann vielleicht auch zum
Beispiel sowas als Fallstrick hat, aber vielleicht auch
andere. Das wollen wir dann halt eben
auch noch mitgeben, dass man halt da vielleicht auch noch mal
ein bisschen aufpassen kann. Genau.
Und was denkst du, was sind so die Tech Home Messages dann, was
ist unser Ziel auch für uns persönlich?
Von den einzelnen Folgen oder von der gesamten Reihe, sowohl
als auch. Na ja, ich würd glaub ich schon
n bisschen gucken oder? Oder mit also so die Frage
beantworten, wie häufig wird so n Pattern im Endeffekt genutzt?
Find ich nämlich irgendwie wichtig, weil da kann man sich
dann nämlich auch selber find ich n bisschen drauf einstellen
um dann zu sagen OK brauch ich das jetzt zwingend ist das ne
Sache ne Sache die ich in mein Näheres oder mein alltäglicheres
Repertoire aufnehmen muss beispielsweise oder vielleicht
nicht? Ne, also wenn du jetzt zum
Beispiel sagst, du hast sagen wir mal n Factory Pattern, das
trifft mal relativ häufig an, würde ich sagen und dann hast du
vielleicht irgendwie n anderes Pattern, was vielleicht manchmal
wirklich sinnvoll ist. Aber eigentlich, wenn du es
nicht kennst, dann ist es nicht schlimm, weil du triffst
vielleicht mit weniger hoher Wahrscheinlichkeit darauf.
Ne, das ist zum Beispiel auch irgendwie was, was etwas dann am
Ende auch an Mehrwert generiert und dass man vielleicht auch
weiß, OK in welcher Situation setze ich das ein, ne, wann ist
es besonders nützlich, wann nicht so für die einzelnen
Beispiele. Und aus der Reihe, was man da
mitnehmen kann, ist natürlich, im Endeffekt soll man jeder, der
sich sozusagen diese Reihe anhört, ein besseres Verständnis
für die Strukturierung von komplexer Software gewinnen und
gerade das, finde ich, ist auch ein wichtiger Punkt, weil
zumindest aus meiner jetzigen Erfahrung natürlich auch mit AI
kannst du dir zwar gut einzelne Funktionen generieren lassen und
auch vielleicht darüber hinaus, aber irgendwann ist hat hat
diese oder haben diese LLMS halt auch die.
Grenzen und die gehen meiner Meinung nach darauf hin, dass
du, wenn du komplexe Software erstellen willst, dann musst du
da selber noch sehr, sehr viel mitwirken und das hilft dir
halt. Ja, guter Punkt, guter Punkt.
Ja, dann würde ich sagen, lass uns in der nächsten Folge der
Reihe einfach mit einem. Erzeugungspattern zum Beispiel
arbeiten, also damit anfangen, wir können, wir hatten jetzt zum
Beispiel ziemlich schon ziemlich viel, das Factory Pattern, ja
ne, damit könnten wir einfach einfach mal loslegen, würde ich
sagen, ist n Klassiker und ist n Klassiker nutz ich auch gerne,
also immer wenn die Situation es hergibt, aber ich mag das
Pattern ja ansonsten fabi würde ich sagen ist es ne
Einführungsfolge ziehen wir es nicht in die Länge.
Liebe zuhören, liebe Zuhörer, falls du ein Lieblingspattern
hast, lass es uns gerne wissen. Wir, wir diskutieren da gerne
drüber, aber jetzt nicht, dass wir es kritisieren, sondern
einfach wir möchten einfach gerne Eure Meinung hören oder
möchtest du zum Beispiel n bestimmtes Pattern besprochen
haben, gibt es da vielleicht n pattern wo du dir denkst so ah,
das hab ich nie so richtig verstanden oder?
Irgendwie ist mir das suspekt, warum sollte man das verwenden?
So, das wäre auf jeden Fall auch richtig interessant.
Dann schreib uns wie gesagt die E Mail findest du wie immer in
den Shownotes oder halt auf jedem Kanal den du möchtest.
Wir sind für dich da und werden es lesen und antworten.
Nicht nur wir, auch die ganze Community kommen Discord wie
gesagt alle links dazu in den Shownotes.
Und ja, wenn dir der Podcast gefällt, wenn du sagst, ey, das
ist cool, die die Folge war gut, der Podcast ist schön, dann.
Lasst doch gerne eine Bewertung da, da freuen wir uns mega oder
empfiehlt es auch gerne 2 deiner Freunden, Freundinnen oder
Freundinnen würde uns auch mega freuen und ansonsten würde ich
die Folge mal so ein bisschen zusammenfassen im Sinne von
guter Code ist kein Zufall, das hatten wir schon mal gesagt,
sondern er ist gut entworfen, in diesem Fall also würde ich sagen
bis zum nächsten Mal. Bis zur nächsten Folge macht's
gut bis dahin. Deine Coding Bytes gemeinsam
besser. Hey Cortana.