Gut erklärt. Ich war Softwareentwickler im Maschinenbau, bin seit etwa 1 Jahr Rentner. Design Patterns habe ich gerne angewandt, obwohl diese im Maschinenbau praktisch unbekannt sind. Im Maschinenbau wird auch heute noch leider maschinenorientiert programmiert. Das erzeugt monolithischen unwartbaren Code. Die Verwendung von Design Patterns setzt allerdings voraus, dass man diese auch verstanden hat. Und das setzt wiederum voraus, dass man die Prinzipien des objektorientierten Designs verstanden hat. Erst dann kann man fundiert entscheiden, ob man ein bestimmtes Design Pattern anwendet, oder ob nicht. Oder, ob man ein bestehendes Pattern modifiziert und dieses dann anwendet. Wer Design Patterns nur anwendet, weil man das halt so macht, wird damit Schiffbruch erleiden.
Inhaltlich echt gutes Video. Der Teil (zB. bei 3:55min), wo das Gesprochene durch einzelne Worteinblendungen untermalt wurde, fand ich leider sehr unangenehm zu schauen und musste extra runter scrollen, da es total vom Inhalt abgelenkt hat. Diese modernen ADHS-Text-Schnitt-Einblendungen passieren meiner Meinung nach nicht zu so einem Thema, wo man gut zuhören will. Gibt trotzdem einen Daumen hoch, war wie gesagt inhaltlich ein gutes Video.
Singleton würde ich eher unter der Kategorie Anti-Pattern einsortieren. Seit dem ich DI-Container mit Singleton als Laufzeitverhalten nutze, habe ich das nie wieder benötigt. Und wenn ich im Code gesehen habe dass andere es nutzen, dann immer falsch (Stichwort superglobale Variablen).
Wieso "Anti"? Du nutzt doch exakt das "Singleton"-Verhalten, im Gegensatz zu "viele Instanzen". Nur dass es eben dein Framework schon bereitstellt, und du es nicht wie zu Zeiten des GoF-Buchs von Hand implementierst. Der Kern von "Pattern anwenden" ist ja, ein gewisses Meta-Verhalten zu erkennen bzw. zu nutzen.
Decorators sollte man selbst wirklich nur schreiben wenn man weiß was man tut. Sie machen, wenn sie Fehler auslösen, das debuggen sehr schwer, da fast niemand auf die Idee kommt die Fehlersuche in einem Decorator sondern fast immer im dekorierten Code selbst zu starten. Frameworks und Programmiersprachen bieten aber oft selbst Decorators an die man dann auch nutzen sollte.
Kommt auch ganz drauf wo man sich bewegt. Also welcher Softwarebereich. Ehrlich, wenn ich einen Bootloader programmieren muss für ein eigenes Betriebssystem dann werde ich nichts aber auch wirklich nichts hiervon verwenden. Oder ich an einer Grafikdemo arbeite die in Assembler programmiert ist. usw. Oder zu DOS-Zeiten ein TSR. Es gibt sehr viel sehr gute Software die von wirklich sehr sehr guten und auch erfolgreichen Entwicklern programmiert wurde wie TeX z.B. von Donald Knuth. usw. wo ich glaube diese Coding Geheimnisse so auch nicht zur Anwendung gekommen sind. Oder wirklich sehr komplexe Software wie LLVM/CLANG und generell der gesamte Bereich CompilerBau. Und leider sind mir zu oft CodeStellen vorgelegt worden wo man auch gemeint hat mit einen tollen Singleton- oder Factory Pattern alle Probleme hat erschlagen können. Und es ist halt sehr davon abhängig von welcher Art die Software ist. Und hier gehts glaube ich mehr um Entwicklung mit TypeScript/JavaScript. Was ich persönlich nicht unbedingt als Softwareentwicklung betrachte. :)
bro was das eine Designpattern mit der calculator klasse wo du die funktion Hookst ( w t f wie lustig das das einfach in der sprache implementiert ist) um die Logs hinzuzufügen?! ich habs gefühlt, das ist koompletter boilerplate code ich würde wirklich immer so simpel wie möglich halten.
Das Singleton ist ein Antipattern, wenn du es zu seinem Nachteil gebrauchst. Aber es hat seine Daseinsberechtigung. Und es ist ein einfaches Pattern und leicht zu verstehen. Wie im Video erwaehnt.
@@Wolkenkeller Ich seh echt keine Daseinsberechtigung für das Singleton. Es macht mehr Probleme als es löst. Was es löst, kann man durch andere Muster (DI, IoC) viel besser erreichen. Erich Gamma von den GoF hat in einem Interview 2009 selbst gesagt, dass er es bedauert, das Singleton je ins Design-Pattern-Buch aufgenommen zu haben. Dass es so einfach und leicht zu verstehen ist, macht es noch schlimmer. Man präsentiert es unkritisch Anfängern, denen man Entwurfsmuster erklären will. Die glauben dann, es ist eine gute Idee und versauen sich damit ihren Code. Also: Sagt nein zu Singletons.
@@thomasforster2674 Ach was. Auch ein Singleton kann, je nach Fall, nützlich sein. Es gibt nicht das allein seeligmachende Pattern. Es mag etwas überspitzt formuliert sein, aber das beste Pattern ist das, was der Programmierer verstanden hat und anwenden kann.
Als jemand der sich etwas PHP, AutoIT, Java etc. selbst beigebracht hat würd ich sagen - Ach du kacke. Ich hab praktisch gar keine Ahnung wie jeweils dein 2. Beispiel funktioniert. Ich würde das eher in funktionen packen und bei problemen die Funktionen anpassen. Und ich akzeptiere, dass das vielleicht schlecht ist
Gut erklärt. Ich war Softwareentwickler im Maschinenbau, bin seit etwa 1 Jahr Rentner. Design Patterns habe ich gerne angewandt, obwohl diese im Maschinenbau praktisch unbekannt sind. Im Maschinenbau wird auch heute noch leider maschinenorientiert programmiert. Das erzeugt monolithischen unwartbaren Code.
Die Verwendung von Design Patterns setzt allerdings voraus, dass man diese auch verstanden hat. Und das setzt wiederum voraus, dass man die Prinzipien des objektorientierten Designs verstanden hat. Erst dann kann man fundiert entscheiden, ob man ein bestimmtes Design Pattern anwendet, oder ob nicht. Oder, ob man ein bestehendes Pattern modifiziert und dieses dann anwendet. Wer Design Patterns nur anwendet, weil man das halt so macht, wird damit Schiffbruch erleiden.
Gutes Video. Für eine andere Sichtweise empfehle ich „Design patterns? bloß nicht!“ von the native Web gmbh ;)
Inhaltlich echt gutes Video.
Der Teil (zB. bei 3:55min), wo das Gesprochene durch einzelne Worteinblendungen untermalt wurde, fand ich leider sehr unangenehm zu schauen und musste extra runter scrollen, da es total vom Inhalt abgelenkt hat. Diese modernen ADHS-Text-Schnitt-Einblendungen passieren meiner Meinung nach nicht zu so einem Thema, wo man gut zuhören will. Gibt trotzdem einen Daumen hoch, war wie gesagt inhaltlich ein gutes Video.
Werde ich berücksichtigen, danke dir :)
Singleton würde ich eher unter der Kategorie Anti-Pattern einsortieren. Seit dem ich DI-Container mit Singleton als Laufzeitverhalten nutze, habe ich das nie wieder benötigt. Und wenn ich im Code gesehen habe dass andere es nutzen, dann immer falsch (Stichwort superglobale Variablen).
Wieso "Anti"? Du nutzt doch exakt das "Singleton"-Verhalten, im Gegensatz zu "viele Instanzen". Nur dass es eben dein Framework schon bereitstellt, und du es nicht wie zu Zeiten des GoF-Buchs von Hand implementierst. Der Kern von "Pattern anwenden" ist ja, ein gewisses Meta-Verhalten zu erkennen bzw. zu nutzen.
Decorators sollte man selbst wirklich nur schreiben wenn man weiß was man tut.
Sie machen, wenn sie Fehler auslösen, das debuggen sehr schwer, da fast niemand auf die Idee kommt die Fehlersuche in einem Decorator sondern fast immer im dekorierten Code selbst zu starten.
Frameworks und Programmiersprachen bieten aber oft selbst Decorators an die man dann auch nutzen sollte.
Kommt auch ganz drauf wo man sich bewegt. Also welcher Softwarebereich. Ehrlich, wenn ich einen Bootloader programmieren muss für ein eigenes Betriebssystem dann werde ich nichts aber auch wirklich nichts hiervon verwenden. Oder ich an einer Grafikdemo arbeite die in Assembler programmiert ist. usw. Oder zu DOS-Zeiten ein TSR. Es gibt sehr viel sehr gute Software die von wirklich sehr sehr guten und auch erfolgreichen Entwicklern programmiert wurde wie TeX z.B. von Donald Knuth. usw. wo ich glaube diese Coding Geheimnisse so auch nicht zur Anwendung gekommen sind. Oder wirklich sehr komplexe Software wie LLVM/CLANG und generell der gesamte Bereich CompilerBau. Und leider sind mir zu oft CodeStellen vorgelegt worden wo man auch gemeint hat mit einen tollen Singleton- oder Factory Pattern alle Probleme hat erschlagen können. Und es ist halt sehr davon abhängig von welcher Art die Software ist. Und hier gehts glaube ich mehr um Entwicklung mit TypeScript/JavaScript. Was ich persönlich nicht unbedingt als Softwareentwicklung betrachte. :)
Arbeite zurzeit bei Apple und hast recht!
bro was das eine Designpattern mit der calculator klasse wo du die funktion Hookst ( w t f wie lustig das das einfach in der sprache implementiert ist) um die Logs hinzuzufügen?! ich habs gefühlt, das ist koompletter boilerplate code ich würde wirklich immer so simpel wie möglich halten.
Nvm ich glaub ich hab nicht genug erfahrung in großen projekten
Das Singleton ist ein Antipattern. Wieso es immer noch gleich als erstes als Beispiel für Patterns herhalten muss ist mir ein Rätsel.
Das Singleton ist ein Antipattern, wenn du es zu seinem Nachteil gebrauchst. Aber es hat seine Daseinsberechtigung. Und es ist ein einfaches Pattern und leicht zu verstehen. Wie im Video erwaehnt.
@@Wolkenkeller Ich seh echt keine Daseinsberechtigung für das Singleton. Es macht mehr Probleme als es löst. Was es löst, kann man durch andere Muster (DI, IoC) viel besser erreichen. Erich Gamma von den GoF hat in einem Interview 2009 selbst gesagt, dass er es bedauert, das Singleton je ins Design-Pattern-Buch aufgenommen zu haben.
Dass es so einfach und leicht zu verstehen ist, macht es noch schlimmer. Man präsentiert es unkritisch Anfängern, denen man Entwurfsmuster erklären will. Die glauben dann, es ist eine gute Idee und versauen sich damit ihren Code. Also: Sagt nein zu Singletons.
@@thomasforster2674 Ach was. Auch ein Singleton kann, je nach Fall, nützlich sein. Es gibt nicht das allein seeligmachende Pattern. Es mag etwas überspitzt formuliert sein, aber das beste Pattern ist das, was der Programmierer verstanden hat und anwenden kann.
Sehr viel Meinung sehr dünn untermauert.
Meine Lieblingsart von Kommentaren.
Dein Strategy Pattern ist unnötig kompliziert. Probiers mal mit Functional Programming, Stichwort Higher Order Function.
Als jemand der sich etwas PHP, AutoIT, Java etc. selbst beigebracht hat würd ich sagen -
Ach du kacke. Ich hab praktisch gar keine Ahnung wie jeweils dein 2. Beispiel funktioniert.
Ich würde das eher in funktionen packen und bei problemen die Funktionen anpassen.
Und ich akzeptiere, dass das vielleicht schlecht ist
Was redet er denn von Betrug...? Was'n Quatsch...