Come on ist nicht dein ernst, dass du es warst? Ja doch, sag mal, es ist nicht dein ernst, dass du das fragst. Ja, wirklich, weiß du. Nicht. Es ist no. Bad Coding Buddies Dein Podcast rund um Softwareentwicklung und aktueller Tech News. Herzlich Willkommen. Halli Hallo und Herzlich Willkommen zum Coding Buddies Podcast. Es ist wieder Zeit für die nächste Folge und zwar mit mir, dem Fabi und natürlich mit Tino, der hier schon wartet. Auf der anderen Seite im Bildschirm.
Tino, Wie geht's? Was geht ab? Fabi Ja, mir geht's gut, mir geht's gut, ja alles fit soweit alles alles fit klingt alles fit, klingst n bisschen fertig hab ich so das Gefühl, aber es scheint zu trüben. Naja weißt du, man will sich ja nicht beschweren, oder wie heißt das immer so schön? Nee alles gut, ich bin n bisschen nicht ganz bei 100% Energie, aber es ist alles nur im grünen Bereich, der eilt hier weißt du manche Tage da ist man
einfach so n bisschen müde. Ja, vor allem vor allem in der Jahreszeit ist das eine ganz normale Sache. Ich weiß auch nicht, das ist halt einfach da, da kommst du nicht drum herum, dass man einfach mal sich denkt, weißt du, morgens stehst du auf, ich finde es ja krass einfach, dieses morgens aufwachen und sich denken, so, es ist noch, es ist noch Nacht oder es ist noch Nacht, guckst kurz aufs Handy oder auf die Uhr und denkst dir so ne, du musst in 10 Minuten
aufstehen, scheiß. Ja, das Frustrierende ist ja, dass eigentlich immer Nacht ist. Ja egal, was du machst. Nur wenn du arbeitest, dann ist nicht Nacht. Aber ansonsten ist immer dunkel draußen. Ja man man kommt halt, man kommt nach der Arbeit auch zu nichts mehr, dann ne also willst also draußen brauchst du gar nichts mehr zu machen eigentlich ne, du kannst nicht laufen gehen falls man laufen geht als Beispiel oder irgendwie weiß ich irgendwas draußen machen, so kannst du vergessen das wird
nicht mehr. Ab 16:00 Uhr das. War ja tatsächlich echt frustrierend, wenn du sag ich mal so ne Laufrute hast. Also ich geh ja ab und zu mal joggen und du hast so deine Route wo du gerne lang läufst, weil es vielleicht so n bisschen in der Natur ist oder so ne, also nicht mit Straßenbeleuchtung sag ich mal und dann wenn der Winter kommt denkst du dir immer so ah nach der Arbeit hätte ich Bock ne jetzt sieht es ja gerade echt noch gut aus und dann ist es halt Instant so.
Oder so sag ich mal nach 10 Minuten einfach stockduster und du denkst sehr gut, klasse, jetzt brauch ich auch nicht mehr loslaufen und dann weiß ich nicht, ich hab auch schon so alternative Routen probiert, so in der Stadt mit Beleuchtung aber das das macht mir dann einfach keinen Spaß. Also falls da irgendwer n Tipp hat schreibt uns gerne aber bitte nicht so Taschenlampe auf dem Kopf oder so mit so einer Kopfleuchte das ist auch geil hab ich auch schon mal gesehen.
Ja, ich bin ja jetzt nicht so der absolut krasse Läuferliebhaber sozusagen, aber ich sag mal so. Ich finde, wenn ich laufe, ja dann find ich es im Winter oder wenn es was heißt Winter. Also es ist ja noch nicht Winter, aber wenn es n bisschen kühler ist schon find ich es einfach besser, weil dann heizt man nicht so auf.
Weißt du ich find es zum Beispiel wenn du wirklich im Sommer läufst so bei annähernd 30 Grad voll schlimm find ich einfach nur weil dann ist einem direkt schon Instant warm und so ist halt wenigstens dir ist kalt dir wird warm alles gut, gutes Level. Ja. Das ist halt dann nur für den Körper natürlich auch ein
bisschen belastender. Ne, weil du schwitzt, aber gleichzeitig ist dir eigentlich kalt, das ist halt irgendwie auch komisch ne immer wenn ich dann irgendwie wieder ankomme und zu Hause bin, quasi merke so meine Arme sind eigentlich übelst kalt und so, aber innerlich kochst du sozusagen. Ja, das ist schon, ich glaube ist auch eine Challenge für den Körper, fürs Immunsystem. Das kann sein ja, auf jeden Fall. Wie gesagt, Laufen Leute
macht's. Ich mag es, ich mag es ja, aber abgesehen vom Laufen wollen wir natürlich heute wieder ein bestimmtes Thema behandeln. Aber bevor wir das machen, Tino, wollte ich noch einmal, ist, glaube ich, jetzt schon ein paar Tage her, aber damit wir es nicht vergessen, wollten wir uns auf jeden Fall noch mal bei Simon bedanken für die Spende für unseren Podcast. Vielen vielen Dank Simon vielen.
Vielen Dank, Simon. Simon hat geschrieben, Mega Podcast, fühle mich sehr abgeholt und wünsche mir auch einen coaling Buddy. Jeder braucht ein coaling Buddy. Leute kommt in die Community, Joint im Discord, da gibt es dann quasi auch n coaling Buddy für jeden. Ich wollt jetzt gerade sagen, da kann man sich n coaling Buddy aussuchen, da sind ganz viele tolle Leute die auch richtig
Bock haben. Genau, und das ist eigentlich, das ist so die erste Anlaufstelle für n coaling Buddy. Richtig, auf jeden Fall. Aber vielen dank Simon und liebe Zuhörerin, lieber Zuhörer, wenn du dir denkst, hey, ja doch eine kleine Spende für die beiden, das wäre irgendwie ganz cool, kannst du auf jeden Fall machen, wenn du möchtest. Nur wenn du möchtest, dann gibt es auf jeden Fall einen kleinen Spenden Link in den Shownotes würde uns natürlich mega freuen, wenn es denn passt.
Sagen wir mal so, aber Tino, bist du bereit, jetzt lass uns mal das Thema starten. Ich denke. Aber wenn ihr jetzt nicht, wenn ihr jetzt nicht ne krasse Überraschung kommt, denk ich bin ich bereit. Das ist schön. OK, denk ich heute, es geht mal
wieder. Wir wollen unsere Reihe fortsetzen und zwar das die Pattern Reihe die Design Pattern Reihe und heute soll es um das Pattern Bridge gehen, also das Bridge Pattern. Lass einfach mal gucken was ist das Bridge Pattern eigentlich mal wieder so ne kleine Analogie geben damit man sich das gut vorstellen kann. Bisschen technischer werden. Wie ist das Ganze aufgebaut und wie unterscheidet sich das eigentlich auch zu manch anderen
Pattern? Also bei mir ist es so ne, wenn ich so manche Pattern habe, über die man dann so spricht, dann denk ich mir so k. Aber du könntest doch auch einfach dieses Pattern nehmen, das klingt genauso, da wollen wir natürlich auch wieder n bisschen abgrenzen, natürlich gucken wo man das gut verwenden kann und wo halt nicht beispielsweise ne, das wär jetzt so der Fahrplan.
Ja. Ja, es ist eigentlich auch n guter Punkt, das zu unterscheiden ist manchmal halt wirklich nicht so einfach, also gerade wenn du jetzt dir verschiedene Struktur Muster anguckst, also pattern aus dem Strukturenbereich, sag ich mal, wir hatten ja zum Beispiel Adapter Pattern schon ne und da ist halt wirklich die Frage OK, wo ist denn jetzt der Unterschied oder wann nehm ich was und sowas könnten wir ja auch mal n bisschen beleuchten
heute, weil das ist halt wirklich ne gute Frage, das ist nicht so Occomon ist nicht dein Ernst. Das ist was ja doch sag mal das ist nicht dein Ernst. Das war ich sehr okay. Ich weiß es gar nicht.
Ist n No Brander, ist n no Brander genau, aber das, also das muss man halt sich wirklich, da gibt es halt kleine aber feine Unterschiede, wie man so schön sagt und da da möchte ich dann gerne, erinner mich dran, dass wir da später noch drüber reden, aber kommen wir erstmal zum neuen Pattern, was wir heute besprechen und zwar das Bridge Pattern, also wir lassen das Adapter Pattern noch mal n bisschen beiseite.
Und ich würd sagen, wir starten einfach wieder mit ganz klassischen Analogien. Und zwar ich finde, wir sind es unseren Zuhörern und Zuhörern, Zuhörerinnen und Zuhörern so einfach schuldig, dass wir auch wieder n bisschen in den Bereich des Essens gehen. Also das ist einfach unser Markenzeichen in dieser Reihe und das sollten wir auch tun. Bei den Pattern wird es nur schwierig, es direkt auf Lebensmittel zu Münzen, sag ich mal. Deswegen nehmen wir einfach mal n Restaurant ja und?
Ich stell mir das jetzt gerade mal so vor. Wir beide, Fabi, wir gehen jetzt mal so richtig schön essen. Ja also wir haben hier schick aus, das ist jetzt einfach n Grund zu feiern und ich führ dich jetzt mal so richtig schick aus wir gehen essen und wir setzen uns an Tisch und ein Kellner kommt und fragt was wir denn gerne trinken wollen was wir essen wollen also er nimmt halt die Bestellung auf und jetzt fragt man sich ja OK. Wieso kommt da eigentlich n
Kellner? Also warum kann ich nicht einfach direkt in die Küche gehen und dem Koch oder der Köchin sagen was ich haben möchte und dann soll die Person mir das zubereiten. Ja und das ist nämlich genau das Ding, dass man ja ne Art Brücke baut zur Küche über den Kellner oder die Kellnerin und da genau und über die Brücke auf huckepack Nein denn. Für dich soll ja quasi unabhängig von der Küche sein, wie ich bestelle. Ne also der Ablauf ist doch immer das gleiche, egal welchem
Restaurant du bist. Ja, also es gibt sag ich mal so regelt oder sag ich mal. Im Kern ist es das gleiche, vielleicht ist es mal koordinierter, mal chaotischer, mal witziger, mal n bisschen gehobener, wie auch immer, ja, aber im Kern ist es ja das gleiche, ich möchte was zu essen haben und ich möchte was zu trinken haben und das wird. Bei dem Kellner oder der Kellnerin bestellt. Diese Person geht in die Küche und übermittelt deine Bestellung entsprechend dem Essen was da ist sag ich mal.
Machen wir es noch n bisschen konkreter, ich nehm eine Nummer ja ich sag ich mir, ich hätte gern zu essen, hätte ich gern die Nummer 5 und der Kellner sagt OK und sagt in der Küche einmal Nummer 5 bitte. Jetzt ist Nummer 5 natürlich auch in jedem Restaurant was anderes.
Ja keine Ahnung in in so nem Brauhaus ist es Schnitzel irgendwas und beim Italiener ist es jetzt keine Ahnung Spaghetti carbonara danke ich weiß du kennst dich aus mit den Nummern bei Italienern, denn das ist die 5 ist immer was Spaghetti und da sieht man ja schon ich brauch ja irgendwie. Eine Instanz oder ein Muster? Was mir genau das ermöglicht, und zwar ich kann unabhängig von der Küche bestellen.
Ja, also dieser Ablauf ist immer gleich und die Küche kann unabhängig von dem wie ich bestelle, einfach das Essen zubereiten und ich habe halt ne Brücke dazwischen, die dafür sorgt, dass beides zusammenpasst. Ja, aber ich habe ja nicht. Und jetzt wird es n bisschen konkreter, warum das Pattern existiert.
Ich brauche ja nicht einen Kellner, ja, der sagt, Ich bin ein italienische Küche Kellner oder ich bin ein Brauhaus Kellner oder ich bin weiß denk dir noch was aus sondern es ist n Kellner oder ne Kellnerin die das macht ja die dann quasi dafür sorgt, dass beides zusammenpasst.
Anders gesagt, du gehst bestellst beim Kellner zum Beispiel auf Deutsch in jeder, in jedem Plan jemand noch mal sprachen um n weiteres Beispiel zu geben, so in der Küche, das ist jetzt so richtig richtig n richtig wahnsinniger Italiener, so wie jeder sich das vorstellt, dass jeder dann nur noch italienisch spricht, ja dann kannst du ja gar nicht in die Küche gehen und bestellen, vielleicht so mit n bisschen Handzeichen oder so ne, aber das war es dann auch schon.
Und genau deswegen sagt man, um nicht zu viel Abhängigkeit zu haben, zu viel Kopplung oder zu viel Implementierung eines Kellners, um es konkreter zu machen, trenne ich jetzt genau diese beiden Sachen und zwar Implementierung und Abstraktion. Genau. Ich find n anderes Beispiel um um jetzt noch mal ganz kurz vorm Essen um noch mal n bisschen technischer zu werden ist. Für mich so n so n so n Beispiel was was irgendwie total auf der Hand liegt.
So ne Universalfernbedienung weißt du, du hast Universalfernbedienung, kannst damit rein theoretisch sagen wir mal n Fernseher bedienen, Radio bedienen, ne Soundanlage bedienen, du kannst damit halt irgendwie alles bedienen, beispielsweise ne und bist jetzt aber nicht dafür angewiesen, dass du sagst, du hast jetzt eine Fernbedienung für den TV, eine Fernbedienung für n fürs Radio, eine Fernbedienung für die Soundanlage, das ist tatsächlich sogar eher Realität,
aber. So rein theoretisch hast du halt eben nicht wieder so ne klassenexplosion, dass du sagst, du brauchst jetzt für quasi die die Klasse Fernbedienung für TV, Fernbedienung für Radio, Fernbedienung für soundanal, Kellner für italienisches Restaurant, Kellner für japanisches Restaurant, Kellner für was auch immer für n Restaurant ne. Also du brauchst halt nicht diese ganzen wenn wir jetzt auf Klassenebene gehen, brauchst du nicht diese ganzen Klassen, sondern du brauchst n Kellner.
Du brauchst n Restaurant so nach dem Motto Ne. Also du hast natürlich dann verschiedene Implementierungen fürs Restaurant in dem Fall. Aber du hast halt. Eben diesen Kellner weißt du, und das ist halt die Bridge.
Dann wie du meintest ne zwischen dem Restaurant und dem dem Kunden oder der Kundin und ich find es jetzt interessant, weil wir hatten ja so n bisschen gesagt, so ey, ich weiß nicht, wir hatten ja die letztens das decorator Pattern ne und da ging es ja auch darum so, ja. Klassenexplosion vermeiden jetzt ist das ja auch wieder irgendwie ne Art und Weise klassenexplosion zu vermeiden, ne, da könnte man sich ja vielleicht überlegen, so ist das jetzt nicht irgendwie das
gleiche, aber am Ende ist es halt doch wieder was anderes, ne, also es sind halt. Es wird halt für verschiedene Dinge genutzt, weil das decorator Pattern beispielsweise ist ja dafür da, um einem Objekt neue Fähigkeiten zu geben, ohne ne Klasse zu verändern. Das hatten wir ja gesagt, ne, dass du immer ne neue Fähigkeit theoretisch noch hinzufügen kannst. Also weiter dekorieren kannst.
Das heißt die Klasse wird sozusagen also das Objekt einer Klasse wird halt mächtiger und bei einer Bridge ist es halt eben so, dass du halt eben einfach beide Seiten voneinander trennst. Also du hast 2 Seiten. Die du unabhängig voneinander entwickeln kannst.
Also wie du ja auch schon meintest, du könntest ja aus der Küche auf einmal aus der italienischen Küche auf einmal ne griechische Küche machen und der Kellner könnte der gleiche bleiben, ohne dass man sozusagen also den du musst den Kellner nicht verändern kannst, aber die Küche verändern. Du kannst neuen Kellner einstellen, die Küche kann aber die gleiche bleiben. Das heißt ganz genau. Bei dem einen trennst du halt wie du so schön meintest, die Implementierung von der Abstraktion ne und?
Das ist diese, die Bridge sozusagen. Und beim Decorator ist es halt so, dass du halt sagst, ja, ich möchte aber gerne einem Objekt immer mehr Funktionen hinzufügen. Am Ende vermeidet beides ne Klassenexplosion, wie wir ja auch in der anderen Folge gesagt haben. Aber und das ist ja das interessante, Es ist die sozusagen die, was man machen möchte, damit ist was ganz anderes und das jetzt auch mal zur letzten Design Pattern folge zu trennen, ne?
Ja, ich kann auch direkt weitermachen, weil so Analogien da auch hilfreich sind. Wenn du jetzt, wir hatten ja auch schon das Adapterpad angesprochen, ich finde, wo man das auch mit der mit der Bridge gut auseinanderhalten kann, ist auch ein Beispiel, was einfach jeder kennt, so dieses typische Ich möchte mein Handy laden, ja und wie sieht das heutzutage aus? Du hast Netzteil was im Prinzip sagt. OK, mit mir kann man laden,
sozusagen. Ja, also ich steck mich in die Steckdose und ich sorg dafür, dass ich n Gerät lade. So jetzt brauchst du aber ne Brücke um dein Gerät mit dem Netzteil zu verbinden und genau das ist ja heutzutage Gott sei Dank auch unabhängig, also quasi getrennt vom Netzteil. Es ist ja nicht mehr so, dass n festes Kabel an dem Netzteil ist, sondern. In der Regel beim Handy sag ich mal NUSBC Kabel. Ja, das heißt du steckst das in dein Netzteil, in dein Handy und du kannst dein Gerät laden.
So jetzt ist es aber so, dass es ja unabhängig ist. Ne das Netzteil auf der einen Seite und das Kabel sozusagen was für deine Funktion jetzt sorgt sag ich mal. Du kannst das gleiche Netzteil nehmen aber NUSBC Kabel ran machen, vielleicht hast du auch noch alte Geräte, wie hießen sie
alle Mini USB? Micro USB da gab es auch 1000 Varianten, bis wir bei USBC waren, kannst du alle nehmen, rein ins Netzteil brauchst du nur das Gerät ne, also je nachdem welche Brücke du sozusagen brauchst am Ende ne. Aber das ist ja Lightning bei Apple, aber das also ja auf jeden Fall, aber das ist jetzt schon so n bisschen so, also das ist auf der einen Seite ist es ja also das was du beschreibst ist ja die Bridge der Bridgepart dabei, aber.
Es gibt ja auch noch n Adapterpart dabei ne, weil du. Ja, das nicht dazu kommen. OK, weil wenn du jetzt zum Beispiel sagst, ich möchte das aber in die Steckdose stecken, ja und bin jetzt aber in einem anderen Land, dann hab ich gar nichts gekonnt, dann hab ich zwar meine meine unabhängigen Implementierungen sozusagen, aber ich kann nicht mehr den Strom nutzen, also brauch ich jetzt an der Stelle einen Adapter um. In die Steckdose wieder zu
kommen? Ja, weil es gibt ja unterschiedliche Steckdosen. So, und da siehst du jetzt,
welcher Teil davon ist. Adapter ne, der sorgt nur dafür, dass ich jetzt in meinem Urlaub, ich hab alles, also es ist alles entschieden meine Geräte, ich bin aber jetzt im Urlaub und merke so Oh verdammt in die Steckdose kann ich gar nicht verwenden ha ich kann aber zur Laufzeit während meines Urlaubs jetzt meinen Adapter verwenden und trotzdem die Steckdose verwenden und gleichzeitig die Kombination und die Brücke nutzen um. Jetzt mein Handy zu laden oder
das Handy vom Partner, wenn der eine n iphone hat und der andere n Android und es gab halt noch nicht die gemeinsame USBC Schnittstelle. Ja also da sieht man ja denn quasi genau die Unterscheidung in dieser Analogie, was ist Adapter und was ist die Brücke? Ja, im Endeffekt. Zumindest so n Kabel finde ich kann man sich als Brücke auch ganz gut vorstellen. Das das stimmt wohl.
Das ist quasi eine eine Kabelbrücke, aber im Endeffekt ist es ja so, wenn wir das zusammenfassen wollen, um das jetzt auch direkt vom Adapter abzugrenzen, ne bridge, ne Trend Dinge halt ne oder sagt lass uns mal Dinge trennen und flexibel kombinierbar machen, das ist ja im Endeffekt die Bridge ne und der Adapter sagt du hast 2 Dinge die nicht zusammenpassen. Na dann lass uns die doch mal so zusammen, dass es passt, dass es passt. Genau, genau.
Und ich finde, und das ist noch mal n ganz interessanter Punkt dabei, wenn du sagst, du entwirfst eine Bridge, ne, dann ist das, dann kann man sich das vorstellen, dass man sagt, lass uns doch mal so n bisschen von, also du bist eher am Anfang eines Projektes, dass du sagst, wir bauen es von Anfang an so am
besten. Um flexibel zu sein, ne, also das ist so ne. Ich sag mal Designentscheidung am Anfang ne wenn wir jetzt bei Software sind n Adapter ist halt eher dass du sagst OK es ist etwas wo du sagst Oh das passt nicht, lass uns n Adapter dazu bauen, das heißt das machst du eher dann am Ende weißt du, dass du sagst das eine planst du von
vornherein. Oder sagen wir mal, in einer frühen Phase deiner Architektur und das Adapter Pattern, da sagst du OK, ich hab das System, ich hab das System, die müssen jetzt nachträglich irgendwie verbunden werden, also bauen wir n Adapter ne. Da hast du wieder die Urlaubsanalogie. Ja, du hast an alles gedacht, du hast den das Netzteil, du hast die Kabel ja das alles so im Vorfeld schön gekauft so mir kann nichts mehr passieren so und jetzt fliegst du in den Urlaub und denkst dir ach
verdammt jetzt muss ich ja doch reagieren und jetzt brauch ich n Adapter. Weißt du, jetzt muss ich quasi, das ist ja nicht eingeplant gewesen vorher. Ja, das, was du gerade meintest, das finde ich, kann man daran jetzt auch wieder gut erkennen. Ja, auf jeden Fall. Oh mein Gott, so eine Steckdose. Ich hab noch nie gesehen und er hat irgendwas basteln. Genau nach Hause rennen, aber. Nee, aber da gibt es so n bisschen off topic.
Es gibt auch richtig geile Reisesets für Steckdosenadapter, so wo einfach weißt du, da hast du ein so n Ding und kannst da sowieso n Transformer alles umbauen und du kommst gefühlt auf jede Steckdose dieser Welt. Das ist gerade für Backpacking und so ziemlich geil, klingt n bisschen nach Kurzschluss für mich hat bis jetzt toi toi toi häufiger Kost, hat immer gut funktioniert ah das ist gut, OK. Auf jeden.
Auf jeden Fall freut mich auf jeden Fall, dass das gut funktioniert, dass ich auch hier so dass du noch keinen Schock bekommen hast. Ja, auf jeden Fall.
Genau das ist das, ich find, das ist ne sehr sehr gute Abgrenzung zum Adapter pattern, weil ich finde gerade wenn du also gerade wenn man jetzt zum Beispiel diese Analogie zum Beispiel mit der Fernbedienung nimmt oder auch mit dem Kellner, klingt das schon alles irgendwie so n bisschen wie n Adapter, aber man sieht halt doch, OK, es ist halt eben nicht einfach ein Adapter, sondern es ist halt, es ist halt für was anderes da ne und?
Wie gesagt, ich meinte ja schon man, also es ist extra dafür um diese um so Systeme zu trennen. Ne in dem Fall wie gesagt ist es austauschbar, du kannst das eine System ohne das andere entwickeln, unabhängig voneinander wie gesagt Küche Kellner kannst aber auch n weiß ich nicht wenn du ne universalfernbedienung hast wie ich meinte kannst du halt auch noch in 10 Jahren zum Beispiel NTV benutzen weil ich sag mal irgendwie die ein und ausschalttaste ist irgendwie
immer noch gegeben. Und wenn wir uns jetzt noch mal so ein bisschen die Struktur angucken, wir hatten ja gesagt, Abstraktion, ne, die Abstraktion wäre ja in meiner Analogie zum Beispiel die Fernbedienung in deiner Analogie, dann der Kellner beispielsweise ne, das heißt, der weiß, was getan werden muss, ne. Also in dieser Abstraktionsebene zum Beispiel gerät an und ausschalten oder zum Beispiel Nummer 5 bestellen, ne so und benutzt halt eben ein Interface
was? Quasi entweder also sagen wir mal das die Fernbedienung benutzen Interface was das Gerät kennt, also zum Beispiel sowas wie ein und ausschalten als Interface oder halt eben der Kellner geht halt eben auch zur Küche ne und benutzt das Interface ich sag mal. Die. Speisekarte ne. Also Nummer 5 ist halt eben dann Spaghetti carbonara oder was anderes was ihr meint und genau so kann man halt eben sagen, wir
können halt. Neue Geräte hinzufügen oder entfernen und es funktioniert alles noch ohne Probleme und wenn wir das jetzt ganze noch mal so n bisschen auf Code ebene, also was also wir haben ja quasi so verschiedene vielleicht Klassen die wir dann brauchen, dafür hast du mal ne kleine Erklärung für wie man das Ganze jetzt so theoretisch aufbauen. Können ja. Also wenn wir jetzt quasi dein Fernbedienungsbeispiel nehmen, also bei den Bridge Pattern unterscheidet man quasi immer.
Struction und Implementation, also die Abstraktion von der Implementierung, ne, dass du beides unabhängig wie wir ja gesagt hatten, behandeln kannst und weiterentwickeln kannst. Und das wäre ja in dem Fall, dass du sagst, die Abstraktion ist jetzt irgendwo meine Fernbedienung. Ja und die Implementierung ist mein Gerät, also mein spezifisches Gerät, das ist das TV Radio was du meintest. Ja und? Das heißt, die Fernbedienung, die weiß, was getan werden soll. Zum Beispiel Gerät ein und
ausschalten. Machen wir es mal simpel, kannst du jetzt auch noch sagen, lauter, leiser würde jetzt auch mappen. Ja, und diese Abstraktion benutzt quasi dann ein Geräte Interface ja, aber ohne wirklich zu wissen für welches Gerät das ist. Ich komm gleich dann noch mal spezifischer dazu. Ja, und um das abzuschließen, die Implementierung ist im Prinzip. Wie ist das technisch gemacht? Das ist dann wirklich die technische Umsetzung.
Ja, von deinem Fernseher, also das der spezifische Fernseher zum Beispiel auch weiß ja was was muss denn passieren, damit ich eingeschaltet werde, was muss denn passieren, damit ich ausgeschaltet werde, wie kann man mich leiser oder lauter machen und das hat halt den Vorteil du kannst jetzt Geräte entwickeln, guck mal hier wir haben n neuen Fernseher, das ist unser neuestes Modell, richtig klasse. Und du kannst auch Fernbedienungen weiterentwickeln, sozusagen. Ja unabhängig voneinander.
Guck mal hier, die Fernbedienung ist aber richtig schön jetzt und die hat übrigens n Knopf weniger. Ja, aber heutzutage ist ein Knopf weniger immer besser, früher konnte es gar nicht genug sein. Kennst du noch diese Fernbedienung wo einfach 1000 knöpfe drauf sind und man sich so dachte Oh ja, guck dir meine Fernbedienung an, die ist krass, oder? Ja ja dann zeig mir mal wo man leiser und lauter macht ah ich
muss suchen kurz suchen. Weißt du, was ich richtig scheiße an meiner Fernbedienung finde? So, ich hab ja n Fernseher so, da hast du dann irgendwie Streamingdienste drauf. Ne so und jetzt ist da n Play Button drauf und n vorspul Button und n Pause Button. Aber der zählt dafür nicht ne. Man könnte sich ja vielleicht denken, ey, ich meine Streamingdienste steuern, aber Pustekuchen, das ganze. Ja. Ich weiß aber nicht, wofür es dann ist. Ah, das ist für Rascha ja nur die Frage.
Ne gute Frage für für den Videorekord. VHS Ja, bestes Gerät. Ah stark OK, kommen wir zurück zur Implementierung, das sieht dann so aus, dass du dann quasi sagst, OK, wenn jetzt meine Abstraktion ein Geräteinterface benötigt ne ohne zu wissen, damit man halt nicht genau den Typ wissen muss. Ja also meine Fernbedienung heißt ich brauch n Interface wieso oft bei dem Pattern? Ich brauch erstmal n Interface und zwar n Geräteinterface das nenn ich dann zum Beispiel Interface Geräte.
Und sag ja, wie soll das Interface aussehen?
Na ja, ich möchte jetzt einschalten können, ich möchte ausschalten können, lauter und leiser, das sind so 4 Funktionen ganz easy erstmal ja OK und ich entwickel so jetzt quasi an der Funktion meiner Fernbedienung, also wie meine Fernbedienung später aussehen soll, ne beziehungsweise was sie unterstützen soll was Geräte können soll um es mal so bisschen abstrakter zu sagen ja. Und gleichzeitig kann ja jetzt jemand anfangen und sagen, ja, OKOK, ich baue jetzt, ich baue
jetzt dieses Gerät. Ja, wir haben jetzt per Interface festgelegt, was das können soll und ich implementier jetzt gerät und bau dir n richtig schönen Fernseher. Ja. So n nagelneuer. Wie groß sind die mittlerweile? Ich bin da nicht so 238000 Zoll 238 Zoll. 1000, bitte. Und ich weiß ja, was der können muss. Also wichtig ist einschalten,
ausschalten, lauter, leiser. Also das sind so die 4 Funktionen jetzt ja und gleichzeitig kann aber Person x aber auch noch sagen ja warte mal, aber ich glaube n Radio wär jetzt auch geil mit den Funktionen ja also jetzt mach ich noch n zweites Gerät was gar nichts mit dem ersten zu tun hat, n Radio halt ja also wir sind jetzt halt nur auf der Tonspur und einschalten ausschalten leiser lauter Krieg ich hin mach ich ja. Das ist denn dein Radio?
Um diesen Podcast hier zu hören, quasi und im Prinzip nutzen beide das gleiche Interface, Geräte oder Gerät ist ja nicht mehr Zeit, gerät wäre eigentlich korrekt und dann kannst du das implementieren und dann hast du im Prinzip von, also der Abstraktionsebene. Brauchst du ja natürlich auch ne Implementierung. Ja, weil ich meinte ja du kannst unabhängig deine Fernbedienung implementieren, das heißt du brauchst natürlich auch ne Implementierung deiner
Fernbedienung und da kommt jetzt der Clou dabei, dass du sagst die hält jetzt ne Referenz zu einem Gerät, was definiert ist. Ja, das heißt die Fernbedienung hält eine Instanz eines Gerätes, was? Was ja abstrakt im Sinne des
Interfaces ist. Das heißt, die Fernbedienung weiß eigentlich gar nicht, welches Gerät das ist, sondern einfach nur OK. Du bist n Gerät und ich kann dich einschalten, ausschalten, lauter und leiser machen und das implementier ich da drin jetzt genau, dass ich sage Funktion mach an nenn ich sie jetzt mal oder mach auf und da sag ich dann OK gerät und Ruf die Funktion einschalten von Gerät auf dann ist mir egal. Wie das passiert?
Mir ist egal, welches Gerät das ist aber meine Fernbedienung, die ich gerade entwickel wird auf jeden Fall die Einschaltfunktion des Gerätes bedienen. Wenn ich sage mach an Knopf, mach an so ne oder bei dir beispielsweise Play auf deiner Fernbedienung, ja ruft ne Funktion auf die einfach gar nichts macht, scheinbar ja, die ist einfach leer implementiert. Richtig.
Ja, im Endeffekt. Da ist ein to do drin, das ist ein to do implement to do. Bald machen wir das im nächsten Sprint. Aber im Ende genau so sieht das dann aus, am Ende ja. Also du hast quasi ein Interface, das Gerät. Du hast halt Implementierung von Geräten, also von einem Gerät was man halt gerne haben möchte und du hast halt eben diese Fernbedienung, die halt wie du meintest eine Referenz auf dem Gerät hat, sodass man dann sagen
kann, ey, ich kann mir irgendwie eine Fernbedienung anlegen und dann da zum Beispiel diese Referenz auf. Reingeben zum Beispiel. Ja, ich möchte ne neue Fernbedienung erstellen für ein TV gerät oder für ein Radiogerät und dann kannst du halt einfach nur sagen Fernbedienung a macht halt, ruft Halt an auf und Fernbedienung B ruft auch an auf und dann werden halt die entsprechenden Geräte. B. Ruft die an, fängt einfach deine Fernbedienung an zu klingeln, aber.
Ja, aber das ist auf jeden Fall so technisch das, was man theoretisch so dafür braucht, um halt dieses Bridge Pattern halt herzustellen, ne oder oder zu zu basteln sag ich jetzt mal ne. Genau. Und den entscheidenden Punkt hast du ja genannt, dass man im Prinzip dann dieser Fernbedienung im Konstruktor üblicherweise das Gerät mitgibt.
Ja, dass du sagst, du bist jetzt eine Fernbedienung mit dem Gerät XY genau die Fernbedienung. Intern weiß nicht, welches Gerät das ist, aber ich kann es von außen vorgeben. Das ist ja der entscheidende Punkt.
Ich kann ja jetzt beide unabhängig implementierten Dinge nenn ich es mal ganz abstrakt, unser Gerät und unsere Fernbedienung kombinieren und sagen, dadurch bist du jetzt ne TV Fernbedienung, so könnt ich jetzt die Variable zum Beispiel nennen, hab aber halt nicht diese klassenexplosion ich muss halt nicht sagen Oh verdammt ich brauch jetzt ne TV Fernbedienung, ich brauch ne radiofernbedienung ich brauch.
Weiß ich was ja für ne Weckerfernbedienung kennt man ganz klassisch ja und das ist halt der Vorteil, dass ich das kombinieren kann, dann am Ende über ne gemeinsame Definition eines Interfaces. Genau. Und das Schöne ist halt, du kannst halt wie gesagt beide Systeme unabhängig voneinander weiterentwickeln. Wenn wir jetzt noch mal wirklich explizite Beispiele nehmen, ne, also zum Beispiel sowas wie dass du. Ne Datenbank austauschbar halten kannst ne.
Also angenommen du hast heute irgendwie ne my SQL Datenbank, morgen nimmst du ne Post SQL Datenbank oder ne SQ lite oder sowas ne und du hast halt keine Lust zu sagen ich möchte jetzt aber überall irgendwie meinem Code diese SQL Unterschiede anfassen weil es ist ja so syntaktisch und immer so n bisschen was anderes ne wie du dann eben diese Datenbank queries an der Stelle machst. Und da kann es dann zum Beispiel helfen, einfach ne Bridge zu nutzen.
Ne, das heißt du hast halt diese Abstraktion, ne diese Database connection und halt eben bestimmte Implementierung dieser Database connection, also was wie ne my SQL connection, postress connection oder nasculite connection ne und dann hast du im Endeffekt also diese Geschäftslogik. Die du hast spricht dann wirklich nur mit der Database
connection. Also das ist jetzt genau dieses dieses Beispiel, ne, dass man wie auch bei einer Fernbedienung, wo man dann ein Gerät reingibt hat, man jetzt zum Beispiel dann am Ende ne Database connection, wo du also ne ne, also ne connection zu deiner Datenbank, die du halt instanzierst die du ansprechen kannst, ne, also sagen wir mal dein ich sag mal dein Database bridge ne wo du am Ende sagst OK aber explizit das in Anführungsstrichen gerät was du
dieser Bridge mitgibst ne ist dann am Ende zum Beispiel dann eben die My SQL Connection oder halt ne andere Connection ne und? Na ja, das ist natürlich n super. Klassisches Beispiel ne wo man das halt in der Regel sehr oft macht, sag ich mal, weil wie du schon meintest, wenn ich die Datenbank austauschen möchte, soll das ja nicht meine restliche Software beeinflussen, sondern ich hab halt wirklich diese Bridge.
Und sag OK, ich hab ne Art Service ne ja den verwende ich, das ist meine Business Logik wie ja füge was hinzu, lösche was ja diese typischen Crute Befehle dann am Ende gib mir alles und. Bitte gib mir alles von dem Table. In der Regel immer erstmal alles. Gib mir erstmal alles und dann ist mir ja egal welche Datenbank da drunter liegt und wenn die ausgetauscht werden muss im Projekt aus gründen warum auch immer ne. Dann wär es ja natürlich toll, wenn nichts davon beeinflusst
ist. Abseits der Implementierung dieser Datenbank sozusagen. Und genau das ist n super Anwendungsbeispiel. Genau, also dann hast du halt diese Brücke wieder und dann rennt einer über die. Brücke ja, warte ich hol die Daten nicht mehr gleich zurück, so weißt du und rennt halt über die Brücke, was auf der anderen
Seite ist, ist uns egal. Sozusagen ne Kleine in Anführungsstrichen Blackbox, aber das Schöne ist halt wie gesagt, du kannst halt eben das System Datenbank unabhängig voneinander entwickeln, kannst sagen OK ich ich. Nee, wir müssen doch was anderes nehmen. Das passt irgendwie nicht mehr aus bestimmten Gründen.
Oder du entwickelst halt eben deine Business Logik auf der anderen Seite weiter und sagst na ja, aber an der Stelle wollen wir jetzt nicht select all haben, sondern zum Beispiel was weiß ich, gib mir mal nur ne entsprechende Teilmenge der Table und dann kannst du das Halt weiterentwickeln und diese Bridge sorgt dafür, dass beides unabhängig voneinander entwickelt werden kann, ohne dass du halt jetzt wirklich sagen musst, ich fasse spezielle Implementierungen an der Stelle
an. Und das ist halt das Schöne an der Stelle. Absolut. Ein anderes Beispiel, was mir da auch recht schnell einfällt, ist so typische. Anwendungsfälle, wo ich unterschiedliche Formate supporten möchte, also beispielsweise Videos oder oder Bilder.
Ja, da gibt es ja verschiedenste Formate und gefühlt, wenn ich irgendwie in dem Bereich was mache, kann ich auch immer alles exportieren in die entsprechenden Formate, ne ah ja exportier mir mal jetzt bitte keine Ahnung, das Bild was ich hier gemalt hab, ja klar was willst du denn für n Format PNGJ Peg? Vielleicht sogar ne Vektorgrafik. Ja, also sag mir was du willst.
Sag mir was du willst, so ne und da muss man sagen kann man ja auch wieder super das Bridge pattern ich wollt gerade Bilder sagen komplett falsch bridge pattern anwenden weil du sagen kannst OK ich implementiere jetzt ne Art Exporter Project Exporter oder Image Exporter ganz allgemein und der sorgt dafür, dass ich sagen kann, was soll denn ermöglicht werden. Ja, also was möchte ich denn exportieren?
Wie soll das Aussehen und hab da so meine Logik drin von meiner inneren Anwendung sozusagen und von außen implementier ich dann sozusagen die das Exportieren an sich. Ja, also wie komme ich denn in das finale Dateiformat? Und das kann ich ja wieder, denn für alle möglichen machen.
Ja, also was hatte ich gesagt, J Peg, von mir aus auch PDF oder sowas gibt es ja auch öfter mal, dass du sagst OK nee, ich möchte aber ne PDF jetzt daraus machen und dann habe ich so verschiedene Klassen die das implementieren. Und dem Exporter gebe ich jetzt quasi zum Beispiel über meine UI wähle ich aus, was ich haben möchte und er weiß dann im Endeffekt, welchen welche Implementierung er denn
verwenden soll. Aber auf der, wenn man sich das jetzt vorstellt sowieso n wieso n Ablauf ne auf der rechten Seite habe ich jetzt quasi die exakte Implementierung wie exportiert werden soll, die Brücke dazwischen und links meine restliche Software und der da muss ja egal sein, welches Format am Ende ausgewählt wird. Soll das Gleiche passieren? Ja. Genau dafür kannst du in das Pattern halt auch nehmen, ne? Auf jeden Fall.
Und ich find da sieht man auch schon ganz gut, wann man es halt zum Beispiel auch wirklich nicht unbedingt verwenden muss. Ne. Also wenn du jetzt wirklich sagst, so, du hast halt keine 2 unabhängigen Hierarchien voneinander, ne, also zum Beispiel jetzt mal jetzt noch mal auf das Datenbankbeispiel zurückgehen, wenn du sagst, ey du hast halt eben. Benutzt nur eine My SQL Datenbank beispielsweise es wird keine andere geben. Wir brauchen das ist felsenfest und mach es nicht komplizierter
als es ist. Dann brauchst du an der Stelle keine Bridge unbedingt, dann kannst du halt rein theoretisch direkt sagen, OK ich schreibe auch meine SQL Queries in meinen Code richtig rein. Weil du sowieso weißt, du musst sie nicht mehr anpassen. Diese zum Beispiel diese Syntax der SQL Queries, die wird sich nicht verändern. Du brauchst also keine Bridge, die dafür sorgt, dass eben das
einfach austauschbar ist. Ne und an der Stelle, dass dass du halt sagst, OK, ich kann jetzt zum Beispiel meine Datenbank unabhängig irgendwie weiterentwickeln, verändern, austauschen, wie auch immer, ne, dann brauchst du das zum Beispiel nicht. Ja, ich find es bei der
Datenbank immer spannend. Weil, wie soll ich sagen, ich hatte jetzt noch nicht oft den Fall, dass ich wirklich grundlegend die Datenbank austausche, ne, aber sehr oft den Fall, dass ich trotzdem unterschiedliche Implementierungen brauche oder mindestens 2.
Deswegen also diese diese Abstraktion an der Stelle oder das Bridgepad, dann ist halt einfach wirklich von Vorteil, allein schon wenn ich sage, ich möchte meine Software ja und das sollte immer der Fall sein, vernünftig abtesten ja, dann ist nämlich auch das Bridgepad dann hilfreich, um zum Beispiel zu sagen, na ja, aber ich kann ja auch ne Testdatenbank implementieren, die genau das macht, was ich jetzt in meinen Tests haben möchte und kann, aber weil ich ne Bridge.
Implementiert habe die einfach verwenden sozusagen. Ist ja auch n Riesenvorteil in Sachen Testbarkeit. Du willst ja nicht in deinen Tests auf der echten Datenbank rumhacken, beispielsweise wenn du jetzt wieder ne harte Kopplung hast am Ende also deswegen also dieses Bridge Pattern oder oder allgemein Pattern, die wir besprechen helfen ja auch in solchen Fällen und nicht nur um. Mehrere Sachen zu unterstützen oder flexibel zu sein, ja sehr
wichtig. Also ich finde gerade der Testgedanke ist halt auch immer eine Form, die ich bräuchte, dabei sozusagen oder eine Variante, wie man es jetzt
nennen möchte. Ja, gerade wenn man zum Beispiel wirklich an den Punkt kommt, ich finde das Beispiel was du gebracht hast wirklich sehr sehr gut, weil wenn du jetzt zum Beispiel weil wenn du jetzt zum Beispiel sagst, und das ist immer ein gutes Anzeichen dafür, du überlegst dir, wie du etwas testen kannst, ne und merkst, es ist nicht gut testbar so.
Dann und du dann zum Beispiel vielleicht so ein Pattern nimmst, um dann zu sagen, OK, jetzt kann ich es aber viel besser testen, ist es meiner Meinung nach auch auf jeden Fall ein sehr sehr gutes Anzeichen dafür, dass dein Code quasi
improved ist. Ne, dass du sagst, ey warte mal, du hast jetzt etwas, also du nutzt zum Beispiel ein Pattern um halt die Testbarkeit zu verbessern, nicht unbedingt nur den Code an sich, aber die Testbarkeit zu verbessern, dann hat es auf jeden Fall was gebracht. Also es ist auf jeden Fall ein sehr sehr guter Punkt für nicht
zu sagen, achtet auch. Nicht nur darauf, dass keine Ahnung man jetzt so Lehrbuch nach irgendwas verknüpfen kann oder so, sondern halt eben auch den Faktor Testbarkeit mit einzubeziehen. Ne? Ja, absolut, wirklich. Weil meistens ist es, wie du ja meintest n Indikator dafür, ob die Software besser wird oder auch robuster. Natürlich ne und sollten dann quasi die Unterscheidung oder die die unterschiedlichen Implementierungen doch auftreten, dann bist du halt
drauf vorbereitet. In dem Moment, weil du schon, also anhand deiner Tests gesehen hast, ich bin in der Lage, das zu skalieren oder variabel zu halten beispielsweise ja,
definitiv. Ich würd zum Beispiel noch sagen, wenn du jetzt also, wo man es jetzt vielleicht nicht unbedingt benötigt, wenn du jetzt zum Beispiel sagst, du hast irgendwie ne, du schreibst ne Software und du deine Software ist eigentlich relativ einfach Straight Forward, da ist jetzt nicht so viel rechts und links, du musst auf gar nicht so viel achten, das ist ne wirklich kleine Anwendung, das heißt?
Die Einfachheit ist wichtiger als die Flexibilität an der Stelle, weil du die Flexibilität gar nicht brauchst. Dann ist es natürlich auch nicht unbedingt notwendig oder ratsam, das Bridge Pattern zu verwenden, weil du halt wie bei vielen Dingen, wenn du es nicht brauchst und trotzdem ein Pattern nutzt, hast du halt immer ein Overhead, ne, also. Von den entsprechenden Interfaces.
Also du hast mehr Interfaces, logischerweise ne wie zum Beispiel das Gerät Interface oder halt höhere Abstraktionsebenen, die natürlich auch Code wieder komplexer machen. Ja ich also ich find es ist so n bisschen kleiner trade off, sorry du wolltest gerade noch was sagen, aber es ist so n kleiner trade off zwischen finde ich. Was brauchst du jetzt schon und was brauchst du in der Zukunft, um zu sagen, das brauch ich
gerade nicht? Das brauch ich definitiv nicht in der Zukunft und ich muss mich quasi schon mal im Vorfeld darauf einstellen, dass ich das vielleicht noch brauche und mein Code flicks, also ich sag mal erweiterbar genug halte um sowas eventuell dann später nicht in einem riesen Refactoring umbauen
zu müssen. Ja, aber das war auch genau das richtige Stichwort. Schon Refactoring angenommen, ich habe es am Anfang nicht auf dem Schirm gehabt, dass ich das zukünftig brauchen werde oder die Bedingungen haben sich so extrem geändert, dass es nicht absehbar war, ist das natürlich auch kein Weltuntergang, weil man kann ja refactor, man sollte Refactor und refactor ist auch n wichtiger Schritt in jedem Projekt, auch wenn viele das, ich sag es provokativ so und
dann Teppich kern sagen, ja nee, keine Zeit für, aber genau das.
Ist ja der Schritt, der dann, sag ich mal ansteht zu sagen, Na ja, aber jetzt mit unseren neuesten Erkenntnissen wissen wir, es wäre besser, jetzt auf zum Beispiel das Bridge Pattern zu setzen und wir haben es gerade alles gekoppelt, wir müssen uns jetzt Zeit nehmen, das umzubauen, man kann es ja umbauen, es ist ja nicht so, dass es für immer fest verdrahtet ist und du entweder das Projekt Wegschmeißt und neu machst mit dem Bridge Pattern oder es halt so lassen musst.
So ist es ja nicht, ne, das stimmt. Und ich find den anderen Punkt auch gut, wenn Einfachheit oder sag ich mal dein Projekt an sich schon verlangt, dass du sowas gar nicht in Betracht ziehen sollst. Ne, dass du halt so spezifisch etwas implementierst, wo es einfach wirklich gar nicht sinnvoll ist, irgendwelche Flexibilität drin zu haben. Nehmen wir mal noch mal das Beispiel Datenbank. Ja also oder ne Anwendung n klassisches Backend mit einer Datenbankanbindung.
Ja, das allein wie wir meinten mit der Testbarkeit, weil ich halt auch mit mit einer Datenbank arbeite bietet sich das schon an so das flexibel zu halten. OK gut würde ich sagen gover it wenn ich jetzt aber keine Ahnung ich bin jetzt n Embedded Entwickler und ich schreibe Software für ne ganz spezifische Mikrocontroller ja und? Welche Flexibilität möchte ich denn da jetzt haben, wenn ich wirklich auf dem Mikrocontroller arbeite?
Also wirklich auf ne ganz spezifische Implementierung hin arbeite, dann kann man sich halt fragen, muss ich das jetzt machen, killt mir der Overhead nicht vielleicht sogar Performance am Ende und das sind halt genau die Unterscheidungen, ne also projektspezifisch zu unterscheiden macht das jetzt Sinn oder nicht? Ja find ich auch n sehr gutes. Beispiel aus dem Real Life, wie man so schön sagt, wo man dann das nicht braucht, vielleicht n Adapter später mal.
Aber ja genau, Adapter löten dann was ich damit oder n anderes Beispiel ja wenn du irgendwie ne Software schreibst die auf mehreren Betriebssystemen laufen soll. Das das ist auch schon so n Indikator wo du sagst na ja gut, ich werde ja Unterscheidung in dem Betriebssystem haben wie die das umsetzen möchte, aber eigentlich das Gleiche von denen
abverlangen sozusagen. Dann hab ich schon wieder so vom Gedanken her wow, da macht das Sinn, ja oder in Frontends oder so ne App Entwicklung cross Plattform was es denn alles so gibt halt ne da da macht das alles Sinn aber es gibt halt auch Fälle und da geh ich absolut mit wenn Leute das sagen so. Ey, ganz ehrlich, dieses Projekt ist nur für diese eigene Plattform, wozu?
Na, weißt du? Und ich find das ist halt wieder mal das Stichwort, weil es einfach wichtig ist, sich genau zu überlegen, wofür man eigentlich was codet und nicht einfach nur sagt Ey, ich hab hier mal gehört Bridgepattern ist voll geil, das müssen wir auf jeden Fall nehmen. Bringt nichts, wenn du es eigentlich gar nicht brauchst.
Deswegen das ist halt das wichtige und deswegen ist es halt auch gut, dass wir auch diese ganzen Pattern vielleicht noch mal nicht nur also auch für uns sag ich jetzt mal auch einfach noch mal durchgehen, weil es einfach auch interessant ist, sich das noch mal in die Gedanken zu rufen, um zu sagen, OK das dieses Pattern gibt es und wann kann man diese solche Pattern eigentlich überhaupt benutzen und man sollte sie halt nur benutzen, wenn sie halt wirklich auch.
Wichtig oder dringend sind ne, was nicht heißt, dass man sie nicht auch einfach mal implementieren kann, einfach so zum Spaß um es mal gemacht zu haben. Ne hatten wir auch schon mal gesagt ja ich find das ist auch n extrem guter Punkt, weil wir das glaub ich in der Community als Frage hatten wie man sich die ganzen Pattern denn merken kann und ob wir uns denn alle merken und da haben wir ja auch ehrlich und transparent geantwortet, so wie wir es hier
auch sagen. Ja natürlich merkst du dir nicht alle. Ja, du hast irgendwann welche, die du vielleicht gerade im Projekt verwendest.
Dann hast du die auf dem Schirm oder so Evergreens, die du halt schon wirklich oft verwendet hast, wie jetzt ne Factory beispielsweise in unserem Fall jetzt nur von uns gesprochen, die haben wir halt öfter schon mal verwendet, weil die oft cool kommt, sagt man so ne, aber es gibt du kannst dir natürlich nicht alle Pattern merken, also bin ich der Meinung und das ist auch völlig in Ordnung, wichtig ist aber sie.
Mal zu verstehen und zu verinnerlichen, dass wenn ich wieder auf sie stoße, verstehe, warum sie da sind oder warum sie benötigt werden. Ja ja und ansonsten hört man entweder hier wieder in unsere Reihe rein oder es gibt halt auch coole Zusammenfassung im Netz dazu und dann frischt man das auf. Und dann ist gut. Genau. Dass und da noch mal so n bisschen den Druck rauszunehmen, weil wir angeschrieben wurden. Oh mein Gott, ich kann mir die alle gar nicht merken, so, ja.
Nee, da ist es auf jeden Fall. Vielleicht implementiert man ja auch einfach mal n Pattern, ohne eigentlich genau zu wissen, wie das Pattern heißt, ne, also dass du jetzt wirklich sagst, ja klar, das ist jetzt das Bridge Pattern und das macht man, weil.
ABCDE so, sondern wenn du einfach nur verstanden hast, wofür etwas da ist, kannst du es einfach anwenden, auch ohne dass du jetzt sagst, ja, das ist jetzt das und das Pattern und das macht das und das und das verwendet man da und da und da und da nicht so ne, dass man einfach so gesagt hat, die Intuition dafür bekommt das Halt zu machen und. Deswegen ja, weil du hast halt die Zielsetzung, du weißt ja, was du erreichen möchtest. Und dann?
Sag ich mal. Ja, viele Wege führen nach Rom, so ne. Dann heißt es vielleicht nicht, dass du jetzt exakten Bridgepattern umgesetzt hast, aber du hast versucht, diese diese Vorteile, diese Benefits zu r coden sag ich mal ne ne und das ist ja auch der entscheidende Punkt am Ende. Ich glaub du jetzt den Bridge da ran, schreibst an deine Klassen oder nicht ja oder ob du die Factory jetzt Factory nennst oder nicht.
Ja, ich glaub im alten Rom hieß es noch aquädukpattern, aber sag ich mal hergestellt ja. Oh Gott, auch hab ich auch gelesen es. Ist es ist schon spät. Ich glaub wir machen. Aber ich denke mir, dass ihr Angst jetzt auch das Fabi, das war der Moment, wo du jetzt
gesagt hast, Schluss für heute. Deswegen vielen Dank für die heutige Folge. Es hat mir wieder sehr viel Spaß gemacht, waren auch hier coole Analogien bei schade, dass wir es nicht direkt auf Essen Münzen konnten, aber ich denke fairnuff wir waren nah dran Burger und genau einfach noch mal so n paar
Lebensmittel nennen jetzt. Deswegen bleibt mir eigentlich nichts mehr weiter zu sagen, als die Frage zu stellen, wieso oft in unserer Reihe, liebe Zuhörerinnen, liebe Zuhörer, hast du schon mal das Bridge Pattern verwendet, wenn ja, wo
und weshalb? Und was sind denn so deine Lieblingspattern, weil wir ja gerade gesagt haben, ja die Factory, die haben wir zum Beispiel öfter im Einsatz, die du häufig verwendest, Teile uns das gerne mit, schreib uns auf der Plattform deiner Wahl, du kannst uns auch ne Mail schreiben. Alle Links und die Mailadresse findest du wie immer in den Show Notes.
Wir freuen uns auf Deine Nachricht, sind immer happy und Antworten auf jeden Fall und auch sehr, sehr gerne ansonsten, falls dir die Folge wieder gefallen hat, Empfiehl gerne den Podcast weiter 2 oder 3 Freunden, das wäre super, lass eine Bewertung da, falls du das noch nicht gemacht hast. Wenn du so richtig dir denkst, so Menschen, Jungs ihr seid der Hammer, ich möchte euch unterstützen, findest du auch einen Spenden Link in den Show Notes, das würde uns mega mega
freuen. Dann vielen vielen Dank dafür. Simon auch noch mal hier noch mal vielen vielen Dank es doppelt hält besser wie man so schön sagt und deswegen wünsche ich euch eine schöne Woche bis dahin bis zum nächsten Donnerstag quasi habt eine schöne Zeit tschau tschau dann kommen wir uns. Gemeinsam besser.