Design Patterns: Die Basis für Clean Coding!
ฝัง
- เผยแพร่เมื่อ 16 มิ.ย. 2024
- In diesem Video erfährst du, wie du deinen Code effizient strukturieren kannst, indem du bewährte Design Patterns anwendest. Design Patterns bieten Lösungen für wiederkehrende Probleme in der Softwareentwicklung und helfen dir dabei, sauberen und wartbaren Code zu schreiben. Dieses Video ist der Start einer Videoreihe zu Design Patterns, in der du Schritt für Schritt alle wichtigen Patterns kennenlernen wirst. Egal ob du Anfänger oder erfahrener Entwickler bist, in dieser Serie erhältst du wertvolle Tipps und praktische Beispiele, um deine Programmierfähigkeiten zu verbessern. Abonniere unseren Kanal und hinterlasse einen Kommentar, wenn du Fragen hast oder mehr über ein bestimmtes Design Pattern erfahren möchtest.
──────────────────────────────────────
► Folge uns
Instagram: / memoryleekde
TikTok: / memoryleekde
Twitter: / memoryleekde
LinkedIn: / memoryleekde
──────────────────────────────────────
► Studieren in Remagen
🧑🎓 www.hs-koblenz.de/mathematik-...
──────────────────────────────────────
► Kapitel
0:00 Intro
0:47 Ursprung
2:27 Kategorien
4:59 Wann einsetzen und wann nicht?
──────────────────────────────────────
► Kontakt
kontakt@memoryleek.de - วิทยาศาสตร์และเทคโนโลยี
Krass, gerade deinen Kanal entdeckt und der ist ja noch total jung und trotzdem schon so professionell. Freue mich wahnsinnig auf die Design Patterns Reihe.
Kommt jetzt jeden Freitag ein neues Video? Finde das ganze sehr professionell und in einer sehr angenehmen Tonlage vorgetragen. Man kann dir gut zuhören
Ja, jeden Freitag ein Video, wir allerdings sehen, wie wir weitere Serien unterbringen.
Tolles Video! Freu mich schon !
Eure Videos haben ein hervorragendes Format! Die Design Pattern der GoF, sind generell eher für das Objekt orientierte Paradigma ausgelegt sind. Im funktionalen Paradigma halten wir uns relativ stark an die Idiome, was auch zu clean code führen kann. Das einzige Problem ist meistens nur, dass viele mit dem Konzept nicht vertraut sind. Vielleicht könnt ihr im Anschluss der Design-Patterns-Serie auch auf FP genauer eingehen?
Ich selbst hab nie professionell mit funktionaler Programmierung gearbeitet, weil es nie eine Anforderung von Unternehmen war. Aber ich sprech mit meinem Kollegen, der darin Experte ist. Vielleicht machen wir dann mal eine eigene Serie zu FP.
@@MemoryLeekDE Wie wäre es generell erstmal die verschiedenen Programmierparadigmen vorzustellen? Ich kann wohl einigermaßen den Unterschied von deklarativen zu imperativem Code verstehen, aber der Unterschied zwischen funktional und objektorientiert, da wirds echt schwammig, wenn man ehrlich ist. Der Rückgabewert einer Funktion ist letzten Endes ein Objekt. Und ein Objekt besteht widerum aus Funktionen
Jo Softwarearchitekturen wären interessant, vor allem in Kombination mit Infrastructure as a Code. Wie man z.B. Python Fabrics, Ansible, etc. mit evt. gängigen Softwarearchitekturen verheiraten könnte, damit Admins/DevOps leichtere Möglichkeiten zum deployment haben.
Ich würde mich über ein Video über die Architecture-Pattern freuen. Für mich als Hobbyentwickler wäre das sicher sehr nützliches Wissen. Ich freue mich schon auf die Design-Pattern Videos, bisher kam ich mit MVP, MVC und MVVM aus. Habe mich kaum mit anderen Pattern beschäftigt, hoffe das noch was dabei sein wird was bei mir noch bessere Struktur in die Projekte reinbringen kann.
Wir werden liefern :)
Ein üblicher Fehler ist es, Design Patterns auf das darin möglicherweise enthaltene Klassendiagramm zu reduzieren. Dieses Diagramm repräsentiert selbst im besten Fall nur _eine_ Lösung, die man aber nur verstehen kann, wenn man das Problem versteht. Der echte Wert eines Design Patterns besteht darin, dass es ein übliches Problem beschreibt und die relevanten Einflussfaktoren explizit macht. Diese Faktoren müssen abgewogen werden und je nach Gewichtung können dann durchaus unterschiedliche Lösungen als geeignet heraus kommen. Das kann dann beispielsweise dazu führen, dass man eine Subject-Observer-Beziehung verwendet, um Codeteile zu entkoppeln. Das kann aber ebenso dazu führen, dass man entscheidet, dass diese Kopplung nicht so schlimm ist und der Aufwand für den Observer sich nicht lohnt.
Klasse Video! An einem Video über Architekturmuster wäre ich durchaus interessiert. In der Vorlesung wurde mir nicht ganz klar, wo man die Grenze, zwischen Design- und Architekturpatterns, zieht.
Bei den Design-Patterns habe ich bisher nur MVC, Observer und Singelton verwendet.
Bei MVC würde mich allerdings mal interessieren, warum es ein Design Pattern und nicht auch ein Architekturpattern ist. z.B. würde ich eine Website mit dem MVC aufbauen, was aus meinem Denken, dann auch eine Architekturpattern sein muss, da ja die Software nach Model, View und Controller aufgebaut wurde. Gibt dann ja quasi die Architektur des Systems vor, an die man sich halten soll.
Wir sind dran, ein wenig wird es aber schon dauern, weil wir erstmal bei 1 Video / Woche bleiben.
Habe bisher noch nichts von "Design Patterns" gehört aber klingt nice und vielleicht macht es das coden leichter, bin gespannt :D
Auf jedenfall. Wenn man einmal alle kennt, dann hat man sehr viele Aha-Erlebnisse in Bibliotheken, die man sich importiert. "So haben die das also implementiert ..."
Der häufige Fehler ist nur, daß man mit Kenntnis der Entwurfsmuster nur noch in diesen Mustern denkt. Oft sind ganze Teams darauf fixiert.
Unbestritten ist es gut, sich mit den Mustern auseinanderzusetzen, um eine Idee zu bekommen, wie man etwas umsetzen _könnte_ und welche Vor- und Nachteile daraus resultieren. Noch wichtiger finde ich die Anti-Patterns. Da sollte man sich mit der Diskussion auseinandersetzen, wieso die sich als problematisch erwiesen haben. Viele der Anti-Patterns galten einmal als tolle Designpatterns. Ich persönlich würde z.B. das Singleton zu den Antipatterns zählen - wird leider immer noch als super Designpattern gehandelt.
Entwurfsmuster sollte man auch immer in Hinblick auf die Sprache beurteilen. In modernen dynamischen Skripten sind sehr viele Designpattern hinfällig und unnötiger Overhead - sowohl in der Entwicklung als auch zur Laufzeit.
Meiner Meinung nach dienen Design-Pattern nur dazu, Schwächen der verwendeten Programmiersprache oder prinzipielle Probleme in der OOP zu umschiffen. Beispiele: Wenn die verwendete Programmiersprache keine Multimethoden unterstützt, ist man gezwungen, das Visitor-Pattern zu verwenden. Wenn die verwendete Programmiersprache nicht auf Werten dispatchen kann, ist man gezwungen, das Strategie-Pattern zu verwenden. Wenn die verwendete Programmiersprache nur auf Objekten dispatchen kann, obwohl man keine Objekte hat, ist man gezwungen, das Fliegengewicht-Pattern zu verwenden.
Nach Jahrzehnten OOP hinterfrage ich sogar das Konzept insgesamt. Erst einmal mußte ich beim Einstieg in OOP feststellen, daß es nichts Neues unter der Sonne war. Verbundvariablen (records) gab es schon in Turbo Pascal. Die hat man an eine Funktion übergeben. Nun kam Syntax-Sugar hinzu, daß man die Funktion (Methode) direkt ans Objekt klemmen konnte.
Neu waren nur die Zugriffsmodifikatoren. Tolle Sache, man konnte beim Entwurf festlegen, welche Methoden und Eigenschaften als Schnittstelle gelten. Außerdem ersparte einem die Vererbung einiges an Tipparbeit. Mittlerweile gilt Vererbung im Sinne der Kopplung ja schon wieder als ganz ganz böse.
Mit der Zeit stellt man aber fest, daß die Zugriffsmodifikatoren eine Selbstbeschränkung sind, die im späteren Projektverlauf häufig zu riesigen Workarounds und Abstraktionen führen. Da frage ich mich oft: Wäre es nicht sinnvoller, Klassen zu dokumentieren und sich möglichst an die gedachten Schnittstellen zu halten. Manchmal tritt dann der Fall auf, wo vielleicht doch mal ein Eingriff in die Mechanik ein Problem ganz simpel lösen könnte. Auch solche "Mißbräuche" müssen dann dokumentiert werden. (Beim guten alten abgesoffenen Vergaser steckte man einen Schraubenzieher in die Kaltstartklappe, und der Wagen sprang an. War so nicht vorgesehen, aber funktionierte.)
Ich bin der Meinung, man könnte auch "schmutzig" einigermaßen wartbaren, zukunftsträchtigen Code schreiben, und das oft viel schneller und auch laufzeitperformanter. Diese ganze Selbstbeschränkung und Schutz vor dem Team sehe ich heute sehr ambivalent. Eigentlich ist es Ausdruck von wenig Vertrauen in die Kompetenz.
Ich stelle mir manchmal vor, ein hochintelligenter Außerirdischer sieht sich den Code an. Er würde auch verworrenen Spaghetticode schnell überblicken und wahrscheinlich sogar so programmieren, weil es für ihn ein triviales Problem ist. Dann sieht er Unmengen an "strukturierendem" Code, der keinerlei Funktion hat.
Man hört ja immer wieder mach das besser so oder mach das nicht so, aber den Begriff "Design Pattern" höre ich zum ersten mal. Grade Anti-Patterns sind mir dann anscheinend schon öfters auf YouTunbe präsentiert worden. Bin gespannt!
Ich freu mich, dass du mit an Bord bist!
Sehr schönes Video, steht dem Thumbnail in nichts nach.
War Erich Gamma nicht auch der, der mit Kent Beck zusammen JUnit gemacht hatte? Basierend auf SUnit? :D
Design Pattern sind können schon praktisch sein, ich meine … wie oft verwendet ihr einen Iterator? :D
Mir hatte mal jemand gesagt, dass dieses berühmte Buch leicht auf einem Architekturbuch basieren würde.
Solche grundlegenden Dinge wie mache einen Lichtschalter immer neben die Tür. Fenster sollten sich nach draußen öffnen und so weiter.
Dass man sozusagen dasselbe für Software haben wollte.
Ist halt wie mit vielen Dingen, manchmal können Pattern einen auch mega einschränken, aber in 80 % der Fälle ist es gut sich daranzuhalten.
Genau der ist das! Die Großen Denker im Softwarebereich aus dieser Zeit haben oft wirklich großen Impact in vielen Bereichen gehabt. Zeitgenössische Denker sind offensichtlich immer schwerer einzuschätzen!
@@MemoryLeekDE Haha ja :D Gefühlt habe ich in meiner Thesis immer wieder nur die Namen, Kent Beck, Uncle Bob, Erich Gamma etc. gelesen.
Es ist auch echt interessant, wie "klein" die Szene dann doch wieder ist.
Ich habe mich oft dabei entdeckt, Iteratoren zu Schleifen umzuschreiben, und die Laufzeit hat sich ganz erheblich verbessert - die Lesbarkeit als Nebeneffekt auch.
In der Programmierung bin ich ein Ressourcengeizhals.
Dachte der Kanal hat sicher über 100 Tsd. Abos
Wir sind vor 2 Wochen gestartet. Schau in 2 Wochen nochmal ;)