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. 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.