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.