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
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.
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.
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.
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
Auf jedenfall ein sehr guter Gedanke. Ist notiert ... allerdings war es schon auf der Liste, wenn ich ehrlich bin. Es kommt alles nach und nach, ich würde gerne mehr Zeit investieren können und so schneller Content aufbauen, aber die Regelmäßigkeit sollte gegeben sein. Zu deiner Frage: Das Funktionale Paradigma funktioniert komplett anders und hat nur bedingt etwas mit den Funktionen/Methoden in der Objektorientierung zu tun. Die Denkweise ist komplett anders. Es geht sehr viel darum, welche Zustände veränderbar sind und welche nicht. Um genau zu sein, sollte der Zustand in der Funktionalen Programmierung nicht verändert werden bzw. KANN nicht verändert werden. Es gibt meiner Meinung nach nicht genug Entwickler, welche Funktional Programmieren können (Funktional denken können). Daher glaube ich tut es den meisten Entwicklern gut, sich damit zu beschäftigem das verbessert die eigenen Skills (genau wie Design Patterns diese Denkskills verbessern). In der Entwicklung halte ich es aus Arbeitsmarkterwägungen oft für nicht gut einsetzbar. Ein Henne-Ei-Problem ...
Auch wenn es so wirkt, sind wir ja übrigens auch kein "reiner Programmierchanel", sondern ein MINT Channel. Bald kommen Serien zu Mathematik und Physik. Ich hoffe alles bleibt spannend :)
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.
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!
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.
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.
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.
Ja, bitte ein Video zu Softwarearchitekturen.
Tolles Video! Freu mich schon !
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.
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.
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 :)
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
Auf jedenfall ein sehr guter Gedanke. Ist notiert ... allerdings war es schon auf der Liste, wenn ich ehrlich bin. Es kommt alles nach und nach, ich würde gerne mehr Zeit investieren können und so schneller Content aufbauen, aber die Regelmäßigkeit sollte gegeben sein.
Zu deiner Frage: Das Funktionale Paradigma funktioniert komplett anders und hat nur bedingt etwas mit den Funktionen/Methoden in der Objektorientierung zu tun. Die Denkweise ist komplett anders. Es geht sehr viel darum, welche Zustände veränderbar sind und welche nicht. Um genau zu sein, sollte der Zustand in der Funktionalen Programmierung nicht verändert werden bzw. KANN nicht verändert werden.
Es gibt meiner Meinung nach nicht genug Entwickler, welche Funktional Programmieren können (Funktional denken können). Daher glaube ich tut es den meisten Entwicklern gut, sich damit zu beschäftigem das verbessert die eigenen Skills (genau wie Design Patterns diese Denkskills verbessern). In der Entwicklung halte ich es aus Arbeitsmarkterwägungen oft für nicht gut einsetzbar. Ein Henne-Ei-Problem ...
Auch wenn es so wirkt, sind wir ja übrigens auch kein "reiner Programmierchanel", sondern ein MINT Channel. Bald kommen Serien zu Mathematik und Physik. Ich hoffe alles bleibt spannend :)
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.
Sehr schönes Video, steht dem Thumbnail in nichts nach.
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!
Dachte der Kanal hat sicher über 100 Tsd. Abos
Wir sind vor 2 Wochen gestartet. Schau in 2 Wochen nochmal ;)
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.
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.