Design-Patterns? Bloß nicht! // deutsch

[@wasauchimmer]

Danke Golo, hast mir von der Seele gesprochen. Habe dieselbe Erfahrung gemacht. Im Studium war es spannend und wichtig und im nachhinein... all das was du beschrieben hast.

[@thenativeweb]

[gr] Ist doch schön, wenn man nicht alleine mit dieser Erfahrung ist 😊

[@91chk]

Zusätzlich habe ich auch die Erfahrung gemacht, dass Leute (passierte besonders oft im Java Umfeld) übertrieben auf den Einsatz solcher bestehen und dann extrem aufgeblähten Code schreiben, der kein Mensch mehr innerhalb von nützlicher Frist erfassen kann.

[@christianwunder7396]

Ich kann viele Punkte nachvollziehen. Ich habe mal an einem Projekt mitgearbeitet wo es zu dem guten Ton gehörte viele Design-Patterns einzusetzen. Schließlich seien Design Patterns ein Zeichen für gut strukturierten und wiederverwendbaren Code. Das ganze sorgte aber für hohe Komplexität durch die zu lösende Fachlichkeit in Verbindung mit diversen Design Patterns. Gerade als Auszubildender war es schwierig den Code zu verstehen und sich im Projekt zurecht zu finden. Dennoch muss ich sagen, dass das Buch "Entwurfsmuster von Kopf bis Fuß" eines der besten Bücher war die ich gelesen habe. Dadurch habe ich viele Konzepte der Objektorientierten Softwareentwicklung erst verstanden.

[@thenativeweb]

[gr] Das Buch kenne ich nur dem Namen nach, aber jetzt hast Du mich neugierig gemacht … 😉

[@TheOnlyDominik]

Die einzigen Pattern, die man braucht für LOB-Apps sind MVC, MVVM und "I love it" Ctor-Dependecy Injection und dann sollte man noch auf das Software-Design in der Solution achten, Clean Code, Onion, ... und ja sowas wie Singleton ... ist ja Standard.

[@BrigitteIlsanker]

Dem kann ich mich anschließen. Vieles gelernt durch das Buch. Heute ist es oft nurmehr ein netter Nebeneffekt, wenn man beim Lösen eines Problems ein Muster entdeckt. Ist hilfreich bei der Diskussion wenn das Ding einen Namen hat den andere Entwickler auch kennen.

[@thenativeweb]

[gr] 😊

[@thenativeweb]

[gr] bis auf das Singleton stimme ich dir dazu, das würde ich persönlich gerne gegen die Factory austauschen. Aber ansonsten bin ich bei dir, dass man mit relativ wenig gut auskommt.

[@rkunisch]

Was die blinde Verwendung von Design Patterns angeht, gebe ich dir recht. Ich finde aber die sind der perfekte Startpunkt, um sich Gedanken zur Problemlösung zu machen. Ich habe leider öfter schlechten Code erlebt, dem der Einsatz von Design Patterns gut getan hätte, als anders herum.

[@thenativeweb]

[gr] Das hängt wahrscheinlich sehr stark davon ab, welchem Code man so begegnet … bei mir würde ich tendenziell umgekehrt argumentieren, aber wie gesagt, das hängt sicherlich von der persönlichen Umgebung ab.

[@christianhorauf9958]

Hab mein erstes Projekt mit Führungsfunktion damals verloren, weil ich, jung und naiv, auch dachte mit DesignPatterns durch und durch wird das Projekt perfekt. Welch ein Irrtum. Danach folgten einige lange Jahre mit dem Irren durch die Dunkelheit des mangelnden Verständnis, bis ich endlich das Licht von TestDrivenDevelopment für mich entdeckte. Leute, macht es richtig, lernt TDD von Anfang an. 💪

[@thenativeweb]

[gr] Danke für Deinen Kommentar, das finde ich einen sehr guten Rat - Fokus auf's Testen legen, denn das führt automatisch zu einer guten (oder zumindest besseren) Struktur, als wenn man keine Tests hat. Das Schöne ist, dass das Feedback unabhängig davon greift, ob Du nun ein Design-Pattern verwendet hast oder nicht, und man merkt, ob der Einsatz eines Design-Patterns den Code insgesamt voranbringt oder nicht.

[@MrFrankie180]

Trotzdem: auch hier ist wieder wichtig wo man tdd einsetzt. Auch das kann eine Religion werden... IMHO ist es sinnvolle genau zu definieren was man getestet haben will weil es im globalen Zusammenhang wichtig ist. TDD als projektübergreifende Grundeinstellung einzusetzen ist für mich kontraproduktiv. Der Einzelfall kann man auch dagegen entscheiden bis das Problem dann doch zuschlägt. TDD hat auch das "quid custoded custodies" Problem, unter anderen... also: "Wer bewacht die Wächter?"

[@omerg3626]

Tdd hat einen praktischen Nutzen. Man entwickelt schneller weil man bei erfolgreichen test fertig ist und nicht die ganze war oder ear deploy en und manuell testen muss. Agile entstandene Software Produkte sollte man am besten von Anfang an tdd basiert entwickeln. Dann lässt es sich geschmeidiger entwickeln, weil seiteneffekte durch unit Tests gemeldet werden.

[@AlexanderRedmann]

Ich glaube durch Dependency Injection, Reaktive Programmierung, Modularisierung und Testing haben sich die allermeisten Design Pattern zu einem akademischen Konstrukt gewandelt, ganz nett zu Wissen, für das Studium relevant aber für den praktischen Alltag ohne wirklichen nutzen. Durch DI sind die Erzeugermuster obsolet, durch Reactive Programming ergibt sich das Verhalten und die Verhaltensmuster erübrigen sich weitesgehenst und durch gutes Testing und das aufsplitten in kleinere Teile ergibt sich die Struktur von alleine

[@thenativeweb]

[gr] Awwww 🥰

[@alexanderbock7460]

Das war ein netter Streifzug durch die Software Entwicklung der letzten 25 Jahre. es hat mich an vieles erinnert was ich schon fast vergessen hatte. Aber ich würde doch gerne noch ergänzen, dass man den Kontext der damaligen Zeit, als das Buch der Gang of Four erschien, mit berücksichtigen muss. C++ war damals erst einige Jahre alt und in Europa noch sehr neu und ungewohnt. Ich erinnere mich auch noch an Smalltalk, damals auch noch verbreitet. Microsoft machte ziemlich unbeholfene Versuche in Speicherverwaltung und Multitasking. Zu dieser Zeit war das Buch aus meiner Sicht eine echte Revolution. Der fast schon philosophische Ansatz basierte JA auf der Analogie zur Architektur (Hausbau). Darum ist das wohl weniger als das Befolgen festgelegter Muster zu verstehen, sondern mehr als eine Aufforderung in übergeordneten Strukturen zu denken. Diese Denkansätze lassen sich heute gut in UML darstellen.

[@markoschaumburg1286]

Sehr gut erklärt! In den 1990er Jahren waren mir bei der C++ Programmierung die Entwurfsmuster sehr hilfreich, schnell und effektiv wartbaren C++ Code zu produzieren. Wichtiger war mir damals noch die Denkweise zu adaptieren, die bei der Schaffung von Design Patterns dahinter lag, um mit dieser Denkweise und Abstraktionsfähigkeit bedarfsgerechte Lösungen mit eigenen bzw. weiterentwickelten Ansätzen noch effektiver in C++ umsetzen zu können. Würde ich mir meinen Code von damals heute anschauen, würde ich da garantiert nicht mehr durchblicken. Letztendlich führt das Ganze dahin, eine andere Sprachebene zu schaffen. Nicht nur Entwurfsmuster sondern vielmehr CORBA und die Object Management Architecture der Object Management Group waren für mich in den 1990er Jahren eine maßgebliche Grundlage. Nach heutiger Perspektive kann man sich in vielerlei Hinsicht die Mühe sparen, da es mittlerweile geeignetere Möglichkeiten mit neuen Programmiersprachen gibt. Die heutige Zeit in der IT ist geprägt von "Ghost Problems" oder "Geisterproblemen", da eine große Palette von effektiven Möglichkeiten zur Verfügung steht, die grundlegende Probleme bereits gelöst haben. Durch Unkenntnis werden hier jedoch weiterhin Lösungen für Probleme gesucht und womöglich teuer implementiert, die es heutzutage gar nicht mehr zu lösen gilt. Prinzipiell gilt aus meiner Sicht: man sollte sich die Programmiersprache und das Toolset aussuchen, wo man sich auf die Implementierung der Fachlichkeit am besten konzentrieren kann und sich nicht noch mit "künstlichen Sprachebenen" mit ggf. sehr abstrakten Entwurfsmustern beschäftigen muss. Nach meiner Erfahrung ist hier häufig auch eine Vermeidungsreaktion die Ursache, sich als Entwickler möglichst nicht mit der unverständlichen Fachlichkeit auseinander setzen zu müssen und dann erst einmal eine "Innere Plattform" zu schaffen, die Fachlichkeit möglichst generisch abbilden kann, nach dem Motto: "Was dann fachlich gefordert wird ist mir egal" 😂

[@marcotroster8247]

Für mich haben Factory und Strategy immer gut funktioniert, weil man damit vorzüglich Dependency Injection betreiben kann und die Side-Effects bzgl. Testbarkeit wegbekommt. In Kombination mit etwas TDD und Functional Programming führt das bei mir zu sehr hochwertigem, kompaktem Code. Und ja, im allgemeinen stimme ich der Aussage des Videos zu. Ein gutes Design sollte anhand von Metriken wie Informationsgehalt und Komplexität gemessen werden.

[@thenativeweb]

[gr] Danke schön 😊

[@GregorSklorz]

Wo Licht ist, ist auch Schatten. Ist wohl die beste Aussage dazu. Ich schätze sehr die Design Patterns, und hoffe dass sich jeder Entwickler damit auseinander setzt. Und es erst dann kritisiert. Die Alternative macht mir viel mehr Angst. Daher überwiegen die Vorteile erheblich für mich.

[@thenativeweb]

[gr] Mehr lernen ist immer eine gute Idee und sei es nur, um etwas danach fundierter ablehnen zu können. Aber angucken und sich damit auseinandersetzen sollte man auf jeden Fall. Nur vielleicht nicht als erstes 😉

[@silentwater79]

Kann dem zu 100% zustimmen. Vor allem in der Java Welt grassieren Designpatterns wie die Seuche. Da denkt man oft wenn man den Code liest, die veranstalten einen Wettbewerb wer Hello World mit möglichst vielen Designpatterns implementieren kann, so das der Code möglichst unlesbar und schwer zu durchblicken ist. Einfache Sachen werden plötzlich über 10 vererbungshierarchien mit 100 Interfaces bis zur Unkenntlichkeit des eigentlichen Problems verunstaltet. Sieht man vor allem bei vielen Frischlingen von der Uni, die alles nach “Lehrbuch” machen wollen.

[@thenativeweb]

[gr] Enterprise Fizz Buzz lässt grüßen 😉

[@DoomTobi]

Gutes Video! C++ als schlechter Sprache zu bezeichnen, weil es kein structural typing unterstützt ist aber stark verinfacht. Ich würde sagen. C++ ist eine schlechte Sprache, wenn man die Performance nicht braucht und wenn man sie braucht meiden viele schon virtual method calls. Structural typing benötigt Runtime Such- oder Hashingmechanismen um herauszufinden, welche Methode gecalled werden muss. Dies bringt einen erheblichen Performanceoverhead und wäre deshalb meines Erachtens in C++ fehl am Platz. Java/C# brauchen diese Mechanismen auch, um Interfaces zu unterstützen, aber da hat man immerhin die Wahl, ob man es verwendet. Denn das ist etwas das Problem von structural typing: Es wäre sehr schwer ein sinnvolles Design zu finden, dass es erlaubt ein optionales Feature zu sein. Dadurch ist das sehr tief in den Methodenaufrufskonventionen der Sprache verankert.

[@cod3r1337]

Übrigens, dass C++ kein structural typing kann, ist eine Halbwahrheit. C++ nennt das halt "parametrischen Polymorphismus" und implementiert es mit Hilfe von *Templates*, in modernen Auflagen von C++ ergänzt um *Concepts*. Das Problem daran ist nur, dass der Weg von C++ unglaublich kryptisch und ohne viele Jahre einschlägige Erfahrung vollkommen unzugänglich ist - während sich das Duck Typing - Konzept etwa in Go oder TypeScript quasi im Vorbeigehen intuitiv erschließt.

[@andreasfunke843]

Das Video hat mir gut gefallen. Wie Du so schön gesagt hast, kommt es auf den Zweck an. Aber wenn wie in dem Beispiel der Programmierer keine Ahnung hat und die Idee nicht von der Implementierung trennen kann, dann ist das kein Nachteil für Design-Patterns. Und zum Thema Singletons: Klare Zustimmung, Singletons sind ja auch ein Anti-Pattern ;-)

[@Heapsray]

Design Patterns sind in meinen Augen nicht "zu viel des Guten", sondern sie werden oft falsch eingesetzt. Ich kenne von der Arbeit aus mehr Projekte, in denen sie richtig eingesetzt wurden, als andersrum. Sehe aber im privaten und öffentlichen Bereich oft Software, wo das nicht der Fall ist. Bin sehr dankbar, sehr erfahrene und talentierte Kollegen gehabt zu haben. Ja, es war anfangs schwer, aber ich bin sehr glücklich darüber. Design Patterns, wenn richtig eingesetzt, vereinfachen die Software und machen sie nicht komplexer.

[@MadKotai47]

Inversion of Control beim entwerfen von UI Components ist imho ein sehr starkes Mittel um unabhängigere Komponenten mit einem starken feature set zu schaffen. Genauso auch dependency injection.

[@svenjodicke3129]

Sehr guter Kommentar... Sehe das zu hundert Prozent genauso. Wir nutzen auf Embedded Ebene auch diverse Designpattern, zb. das FactoryPattern und das funktioniert im objektorientierten Kontext auch super und hat uns im Embedded Bereich neue Wege eröffnet und ist in unserem Code nicht mehr wegzudenken, aber dennoch appelliere ich immer an meine Programmer-Dudes, dass man nicht auf alles ein Pattern stülpen, sondern immer die Lesbarkeit im Hinterkopf haben sollte. Wie du immer sagst, optimiert auf das Lesen und nicht auf das Schreiben. Das habe ich mir (und ich versuche das auch bei uns zu propagieren) zum Mantra gemacht. Wie so oft im Leben kommt es auf die gesunde Balance an und das nehme ich im Prinzip aus deinem Kommentar mit... Also vielen Dank für diesen tollen Kommentar...

[@lollo4711]

Bei jedem neuen Projekt sollte man in der Planungs- und Konzeptions-Phase immer auch noch mal etwas im Internet gucken, was andere so für Erfahrungen gemacht haben oder wo sie ggf. auch Schwierigkeiten oder echte Probleme hatten - was ggf. neu ist oder was man mittlerweile sogar vermeiden sollte. Bsp: Eine ziemlich große Firma wollte ihr monolithisches Monster-System auf viele kleine (State-of-the-Art) Services verteilen… im DEV-System lief auch alles suuuper!!! - die Überraschung gab´s dann im PROD (riesiges verteiltes System): Jeder Call von Service zu Service brauchte allein nur zur Etablierung der Verbindung 800ms - reine Latenz - bei jedem! Call von Service zu Service… und sie hatten viele Services hintereinander geschaltet - den Monolithen Stück für Stück auseinander genommen und in ganz kleine Teile zerhackt! (das aber immerhin State-of-the-Art:))

[@SeoOderNichtsein]

Ein gutes Video mit einem sehr wahren Kern. Es ist eher kontraproduktiv an allen Stellen Designpattern einzusetzen, nur damit man es nach "Lehrbuch" macht. Das führt zu unnötig komplexen Codes und macht Projekte nicht wartbarer. Zu den von mir am meisten verwendeten Pattern gehören Singleton, Adapter, Observer, Proxy, Factory und Decorator. Das Buch der GOF habe ich nicht gelesen. Ich habe mein Wissen aus anderen Büchern und Tutorials. Dabei habe ich auch bemerkt, dass (wie von dir erwähnt) nicht jedes Pattern für jede Sprache sinnvoll ist. So finde ich zum Beispiel in Fachbüchern für JS Pattern andere als in Fachbüchern für PHP Pattern. Ich finde es auch viel wichtiger, dass man den Gedanken hinter den Pattern versteht. Es ist zwar gut, wenn man weiß, welches Pattern für die Lösung welches Problems genutzt werden kann. Es ist aber meiner Meinung nach noch viel wichtiger, dass man versteht, warum das entsprechende Pattern das Problem löst und warum es genau so aufgebaut ist und nicht anders. Viele Wege führen nach Rom. Man sollte aber im Zweifelsfall verstehen und gut begründen können, warum man den einen Weg gewählt hat und nicht den anderen. Welchen Vorteil hat der gewählte Weg und warum? So etwas wie "Weil es in diesem Buch steht ..." ist für mich da keine ausreichende Antwort ;) Aber um es mit einem Kurzen Satz zum Abschluss zu bringen. Manchmal ist weniger mehr und man sollte sich gut überlegen, wann man ein Designpattern einsetzt und wann nicht. Und das kann einem Kein Buch vermitteln. Das ist Erfahrung.

[@thenativeweb]

[gr] Ein schöner Kommentar - vielen Dank dafür 😊 Das einzige, was mich wundert, ist (und das hattest Du ja gestern im Livestream auch angesprochen), dass Du Singletons häufig verwendest. Gerade mit diesem Pattern stehe ich auf Kriegsfuß, weil es häufig sehr schlecht testbar ist. Wie gehst Du damit um? Aber abgesehen davon: Begründen können, warum man Weg X statt Y gegangen ist, finde ich unglaublich wichtig. Und "Weil es in diesem Buch steht …" ist definitiv keine ausreichende Antwort - im Gegenteil. Das ist mit die schlechteste Antwort, die man bekommen (oder geben) kann.

[@SeoOderNichtsein]

@@thenativeweb Man kann mit dieser "Herausforderung" meiner Erfahrung nach auf zwei Arten umgehen. 1. Man schreibt den Code so, dass man die entsprechende Klasse sowohl als Singleton als auch "normal" instanziieren kann. 2. Man bildet die Instanzen der Singleton-Klassen IMMER außerhalb der benutzenden Klassen und arbeitet mit Dependency Injection. Dann kann man bei den Tests bei Bedarf mit Mocks arbeiten. In beiden Fällen wird das Testen jedoch komplizierter und umfangreicher. Beantwortet das deine Fragen? Oder möchtest du, dass ich auf einen speziellen Aspekt etwas genauer eingehe? Oder hast du noch einen anderen Ansatz?

[@thenativeweb]

[gr] Danke für deine Antwort, dann habe ich verstanden, wie du davor gehst. Das ist auch, denke ich, die einzig mögliche Variante, wie man dem Problem aus dem Weg gehen kann, dass alles hart verdrahtet ist, was einem in den Tests auf jeden Fall um die Ohren fliegen würde.

[@ettoreatalan8303]

In 11:37 wird Ducktyping erwähnt. Kommt dazu auch noch ein Video?

[@thenativeweb]

[gr] Steht seit gerade auf unserer Todo-Liste für die nahe Zukunft 😊

[@ettoreatalan8303]

​@@thenativeweb Auf den Beitrag bin ich schon gespannt😃

[@tommybley2876]

Vielen Dank für den schönen Exkurs und der guten Erklärung. Und das hier ein Thema angesprochen wird, welches unter den Entwicklern immer wieder für streit sorgt. Jetzt bin ich aktuell aber doch etwas verunsichert im verwenden des Singleton Patterns auf welchen ich im aktuellen Projekt gesetzt habe. Hier stößt mir gerade der Punkt, Globale-Variable = Evil weil weniger Testbarkeit + mehr Abhängigkeit im Code, und lieber die Abhängigkeiten über die Argumente in die Funktion geben um diese schließlich vom Code zu entkoppeln. Jetzt ist es beim aktuellen Projekt das Problem, dass ich ein Plugin für eine CAD Anwendung (Revit, mit C#) schreibe. Dieses bekommt zur Laufzeit über die Plugin Main-Funktion einmal das aktuelle Dokument übergeben. Jetzt möchte ich aber eigentlich nicht dieses Aktive Dokument über jede Funktion durch reichen, da ich ja eigentlich auch keine Entkopplung durch das durchreichen als Argument erziele. Immerhin ist das Plugin (Projekt) ohne den CAD-Kontext auch nicht Testbar, bis auf ein paar Service-Funktionen die wir mit einen Unit-Test abdecken. Meines Erachtens ist hier der Vorteil des Singleton in diesen Fall gegeben, da durch die Globale Variable des aktiven Dokuments sowieso eine direkte Abhängigkeit zur CAD Anwendung besteht, somit eine Entkopplung nicht möglich. Desweiteren sparre ich mir in 80% aller meine Funktionen einen weiteren Parameter, welche auch wieder die Leserlichkeit der Funktionen erhöht. (Meines Erachtens) Ich würde es aber generell mal zur theoretischen Diskussion stellen, ob die Wahl des Singleton-Patterns an dieser Stelle auch eleganter und besser zu lösen wäre. LG und Danke fürs Video :)

[@thenativeweb]

[gr] Vielen Dank für das Lob 😊 Das von Dir beschriebene Problem hat man in der Praxis leider tatsächlich so, und da gibt es im Endeffekt auch nur drei Optionen: - Entweder stellst Du das aktive Dokument als Singleton zur Verfügung. - Oder Du reichst es überall hin durch. - Oder Du hast eine Art zentrale "Registry", die als Singleton implementiert ist, die Du für verschiedene Objekte, darunter auch das aktive Dokument, nutzen kannst. Die Option mit dem Durchreichen ist die sauberste und expliziteste, aber leider auch die umständlichste und oftmals nicht zielführende. Bleiben die anderen beiden Optionen, die sich im Wesentlichen nur dadurch unterscheiden, dass es im einen Fall mehrere Singletons geben könnte, im anderen nur eins. Tendenziell würde ich daher eher auf Option 3 setzen, um das Singleton-Verhalten vom aktiven Dokument zu entkoppeln. So richtig toll ist aber keine der drei Optionen …

[@tommybley2876]

@@thenativeweb Vielen Dank für dein Feedback :) im Ende Effekt hab ich tatsächlich Lösung 3, da ich neben dem Dokument leider noch 2 andere Sachen haben, die aus den Plugin-Kontext kommen, welche ich als Parameter bekomme. Aber gut zu wissen das alle 3 Lösungsansätze irgendwie richtig und irgendwie falsch sind :D da sehen wir wieder, dass die Theorie manchmal immer ganz schön ist. Die Praxis uns es aber nicht immer erlaubt die Theorie richtig umzusetzen. Es wäre ja auch geil gewesen, wenn das Entwickler-Studio der CAD Anwendung das aktive Dokument als globale Konstante bereit gestellt hätte, dann hätte ich das Problem nicht :P LG

[@micknamens8659]

Mein Metapher zu Entwurfsmustern ist eine Autobahn. Sie beschleunigt den Verkehr (=Änderbarkeit) entlang ihrer Route, erschwert aber den Verkehr quer zur Route. Bau und Unterhalt verursachen Kosten. Deshalb YAGNI Prinzip anwenden.

[@thenativeweb]

[gr] Das ist ein schönes Bild, danke dafür 😊

[@micknamens8659]

Um Verkehr quer zur Trasse zu ermöglichen, sind Überführungen nötig, oder gar Autobahnkreuze im Fall wenn 2 Entwurfsmuster verknüpft werden. Ein Beispiel dafür ist das Visitor-Pattern, welches das OO Paradigma (welches man auch als ein Mega-Pattern betrachten kann - Variabilität durch Hinzufügen neuer Subklassen) mit dem Funktionalen Programming (FP) Paradigma (Variabilität mittels Funktionen als first-class-citizens Werte) verknüpft. In der FP gibt es auch Lösungsmuster, z.B. Monaden, welche Effekte (z.B. state change und IO Kommunikation) mittels seiteneffektfreier Funktionen und immutabler Werte realisieren.

[@Poperzenknarz]

Wow..... ich bin beeindruckt o_o Hier sitzt ja wirklich jedes Wort. Das is ja wie die Sendung mit der Maus, aber für Software Entwickler 😊 Direkt abonniert.

[@thenativeweb]

[gr] Danke schön für das Kompliment 😊

[@SunSailor]

Volle Zustimmung, auch hier aus der Unity-Welt. Ein Design-Patter muss ein Problem lösen, sonst wird es nicht gebraucht. Die Testbarkeit muss gegeben sein, was schon mal Singletons ausschließt. Statt dessen DI oder Service-Architekturen, ggf. sogar beides. Isolation ist das höchste Gebot, gefolgt von Code-Minimierung - der beste und fehlerfreiste Code ist jener, der erst gar nicht geschrieben werden muss. Wir setzen daher inzwischen auf stark deklarative Ansätze, gekoppelt mit einem MV-VM Ansatz. Da gibt es Klassen, die einzig Member definieren und deren Verhalten ausschließlich über Attribute gesteuert wird. Das ganze skaliert extrem gut.

[@VitalijMik]

Als PHP Entwickler vermeiden wir tatsächlich den Singleton und der ist sogar ein Antipattern in der PHP Welt. Mit den GoF Pattern stimme da ich auch zu, dass die sich sehr stark wiederholen und nur einige Nuancen sich teilweise unterscheiden. Allerdings kamen später noch weitere Pattern hinzu die gar nicht so schlecht waren. Zum Beispiel von Martin Fowler, Criteria Design pattern. Diese Setze ich zum Beispiel oft ein. Eine Zeitlang so um 2015-2016 herum war das Service Locator Pattern auch sehr verbreitet. Das war noch vor Dependency Injection. Man hat einfach in jeden Controller den DI Container übergeben ohne einfach den Service daraus direkt gezogen. Später merkte man, dass es doch mehr Sinn ergibt via Constructor die Notwendigen Klassen zu injezieren statt die einfach frei irgendwo irgendwan nachzuladen. Ich will nicht sagen dass Design Pattern schlecht sind, nutze einige täglich. Allerdings sind die so abstrakt dass die auch missverstanden werden können. Ich kann mir auch gut vorstellen dass diese im Informatik Studium so sehr geliebt werden weil man da was zum Abfragen und Benoten hat. Ähnlich wie UML Klassen Diagramme oder ER Diagramme. Also Bloß nicht wäre da falsch zu sagen sondern wie im Video gesagt "Es kommt drauf auf"

[@thenativeweb]

[gr] Das stimmt, ich habe mich im Video im Wesentlichen auf die GoF-Pattern bezogen. Aber es gibt noch weitaus mehr, und selbstverständlich sind da auch nützliche Dinge mit dabei 😊 An die Service-Locator-Zeit kann ich mich auch noch gut erinnern, wobei das bei mir früher war (das war noch zu .NET-Zeiten, muss also vor 2011 gewesen sein). Aber ja, das war nur ein Schritt in Richtung Dependency-Injection … im Prinzip spielt dieses Pattern (der Service-Locator) heute ja überhaupt keine Rolle mehr, außer im viel größeren Stil in verteilten Systemen als Service-Discovery. Aber das ist eine andere Abstraktionsebene, aber das gleiche Prinzip. PS: Deinen Vergleich zu UML, Klassen- und ER-Diagrammen fand ich sehr passend - vergleicht man Studium und Realität, haben die im Studium einen viel zu hohen Anteil. Aber ja, sie lassen sich gut abfragen 😳

[@VitalijMik]

@@thenativeweb ja ich habe nicht studiert sondern nur eine Ausbildung gemacht und die Diagramme waren in der Abschluss Prüfung. Deshalb kam der Gedanke dass es nur was zum auswendig lernen und abfragen ist. Auch Design pattern. Diese wurden gerne beim Einstellungstest abgefragt.

[@BrigitteIlsanker]

Sehe ich auch so. Musste schmunzeln weil ich im Video auf das Wort Antipattern gewartet habe, es aber nicht kam. 😊

[@thenativeweb]

[gr] Ich wollte damit auch nicht sagen, dass das nur im Studium so wäre, es war bei mir persönlich eben im Studium, aber ich denke, das kann man ganz gut auf Ausbildung im allgemeinen Sinne verallgemeinern. Denn Noten müssen ja all diese Systeme irgendwie generieren… wo man ja durchaus geteilter Meinung sein kann, ob das sinnvoll ist. 😉

[@VitalijMik]

@@thenativeweb ne ich wollte damit andeuten dass in der ausbildung da AUCH viel wert darauf gelegt wurde

[@omerg3626]

Stimme vollkommen zu!! Insbesondere mit Gießkanne Prinzip Einsatz von patterns

[@19nik91]

Ich habe sehr schlechte Erfahrung mit dem pubsub pattern gemacht. Sehr cooles video. 👍

[@thenativeweb]

[gr] Danke schön 😊

[@denkling]

Wow, ein super Vortrag. Ich habe viel gelernt.

[@thenativeweb]

[gr] Vielen lieben Dank 😊

[@GeckoHero]

Sehr gut. Gerade beim Programmieren lernen ist es wichtig, Objektorientierungithilfe einer OOA zu lernen. Pattern sind Ideen die man sich mal anschauen kann, wenn man OO drauf hat. Wer seine Programmiersprache kennt, wird feststellen welche Pattern sinnvoll für seine Arbeit sind und welche nicht. PS: Wenn mir jmd erzählt er arbeite auch Objektorientiert und sagt er nutzt besonders gerne singleton oder er mag statische Methoden lieber ist das die größte RedFlag. Kein Grund jmd aus dem Team zu schmeißen aber ein deutliches Zeichen, dass da jmd noch einen sehr weiten Weg vor sich hat!

[@thenativeweb]

[gr] Danke 😊 Ja, das schlimmste in der Richtung, was ich bislang erlebt habe, sind die statischen Klassen in C# … das ist (war?) im Prinzip nur ein schlechtes Konstrukt, weil man keine Funktionen ohne Klassen definieren kann …

[@blafexe8087]

So schön und sauber erklärt. Super Video!

[@thenativeweb]

[gr] Vielen herzlichen Dank 😊

[@ettoreatalan8303]

9:29: Muss man bei der fachlich konkreten Namensgebung den abstrakten technischen Namen des eingesetzten Entwurfsmuster unbedingt mit einbeziehen oder reicht es auch aus, wenn das Entwurfsmuster in einem Kommentar kurz erwähnt wird?

[@thenativeweb]

[gr] Muss man natürlich nicht - wird nur leider oft gemacht. Also zum Beispiel, dass man ursprünglich const metronome = new Metronome(); hat, dann eine Factory-Method einführt, und damit das hier bekäme: const metronome = createMetronome(); Das dann aber nicht so benennt, sondern dann sowas hier bekommt: const metronome = MetronomeFactory.createInstance(); Wo auf einmal zu viele Wörter (Factory, Instance, create) durch die Gegend schwirren, die mit dem Pattern zu tun haben, aber nichts mit dem eigentlich fachlichen Inhalt.

[@ettoreatalan8303]

@@thenativeweb Könnte die Prüfung auf die Nichtbenutzung abstrakter technischer Entwurfsmusternamen nicht der Linter übernehmen oder würde das bei euren Projekten mit der fachlich konkreten Namensgebung zu Konflikten führen?

[@thenativeweb]

[gr] Das wäre eine interessante Idee, habe ich noch nicht drüber nachgedacht und auch noch nicht gesehen. Aber hat was 😊

[@ettoreatalan8303]

@@thenativeweb Schön, dass meine Idee gut ankommt. Würde etwas gegen die folgende allgemeine Regel sprechen? Fachlich konkrete Namen => Bezeichner Abstrakte technische Namen => Nur in Kommentaren

[@thenativeweb]

[gr] Ja, weil nicht jeder Code eine echte Fachlichkeit abdeckt. Schreibe ich zB Code, der mir automatisiert Singleton-Klassen generiert, dann wäre das tatsächlich eine SingletonFactory 😉 Zugegeben, etwas konstruiert. Aber in Framework-Code gar nicht so abwegig.

[@svensteckmann5623]

Kannst du bitte noch den Link für das double-checked locking ideom in die Beschreibung stellen.

[@thenativeweb]

[gr] Der ist bereits in der Beschreibung, aber ich kann ihn Dir auch hier noch mal geben: csharpindepth.com/Articles/Singleton

[@svensteckmann5623]

@@thenativeweb du hast natürlich recht. Man sollte mal eine Seite runterscrollen. Ich hatte nach einer Seite nur mit dem Ideom gesucht.

[@thenativeweb]

[gr] Die Hauptsache ist doch, dass es sich geklärt hat 😊

[@maxter2403]

Da ich jetzt zufällig auf dieses Video gestoßen bin, schreib ich mal was mir so in der Programmierung immer Bauchschmerzen macht. Du hast es schon gesagt, es sind nur Ansätze in OO . Jetzt wollte ich mal Python lernen & anwenden beispielsweise.(Das Projekt ist Data Mining/Sentiment deswegen Python) Hier kommt man eh durcheinander überall lose Funktionen aber einen OO Ansatz hat es auch und da weiß man als OO-Programmierer nicht genau wo man anpacken soll. Jetzt habe ich mich gerade gefragt, wo du so über Design Patterns sprichst( ist ja Richtung OOA OOD angesiedelt) was zb. die Gegenstücke von OOA, OOD und OOP in der Funktionalen Programmierung wären, weil ich sie einfach nicht kenne. UMLs , Zeichnungen Planung Modelling das alles in der Funktionalen Welt usw. ??? Denn in Python scheint beide Welten aufeinander zutreffen und weil ich im Studium nur Objektorientierung kennen gelernt habe, kenne ich sie nicht ! Ich habe persönlich so schon immer Probleme bei privaten Projekten OOA & OOD zu betreiben und am Anfang frusturiert bin, welche Klasse und welches Objekt ich wie designen soll. In Python bin ich nun noch frustrierter als vorher. Ich habe echt immer das Gefühl "Wie mache ich das jetzt nochmal, kann ich das überhaupt?" Ich habe zich mal Bücher von Balzert durchgekaut und jedes mal stehe ich vor dem selben Problem. Soll ich jetzt Design-Patterns anwenden? Soll ich Vererbung benutzen oder Interfaces bauen, soll ich soll ich soll ich .... Mit Python kann man sich natürlich vorstellen wie ich dann davor stehe. Habt ihr vielleicht Quellen die mir straightforward sagen kann = So machst du Anforderungsanalyse, so beschreibst du die ersten Objekte und Klassen, Tipps darüber ab welchem Zeitpunkt x ich über Design Patterns und Vererbung und Interfaces nachdenken sollte, weil dieser vllt günstiger wäre? Ich würde mir so gerne ein Video von Professionellen mal wünschen OOA & OOD from Scratch wie geht man daran, uns zwar nicht nur an OO geknüpft sondern auch gerne mal funktional oder gemischt wie in Python das der Fall ist. Man findet nichts zu Objektorientiertes Design oder Analyse hier bei KZbin, wenn ja ist es nur die trockene Theorie. Wenn ich diese Grundprobleme habe, wie komme ich dann ans Ziel ? Wissen wir doch alle ich arbeite agil :D Bisschen Analyse bisschen Modelling bisschen Code und Testen des Codes am Ende ist es dann Müll im Sinne von gekoppelte Klassen jeder erbt von jeden zich Unterklassen die eigentlich unnötig wären. Aber ist glaub ich ein generelles Problem denke ich. Ich weß nur nicht ob es nur in Deutschland so ist. Altes Code wird noch mehr zugemüllt anstatt zu re-engineeren. Die Planung wird oft nicht gut genug gemacht etc. etc. Und dieses agile Arbeiten finde ich sehr schwierig wenn es Kunden gibt, die Zeiten und Budgets genau abgeschätzt haben wollen etc. Falls einer Vorschläge, Ratschlag oder Empfehlungen hat nehme ich sie gerne an. Danke :)

[@kyrospace]

Meine Erfahrung als Hobby- bzw. Semipro-Entwickler ist, dass mirEntwurfsmuster an Stellen wo ich nicht sinnvoll weiterkam durch aus geholfen haben. Allerdings habe ich auch die Erfahrung gemacht, dass der Code dann wie gesagt sehr aufgebläht wurde. Deswegen ist mein Fazit: Wenn ich nicht mehr weiter weiß oder der Code so müllig rüberkommt, dann gönn ich mir auch gerne mal wieder einen Blicka auf die DP. So wie das Leben ist auch das anwenden von Entwurfsmuster nicht schwarz und weiß. Und man darf auch nicht vergessen, dass wir über Sprache reden. Und bekanntlich kann man in der selben Sprache das gleiche auf unterschiedliche Weiße ausdrücken.

[@thenativeweb]

[gr] Das stimmt - und genau dieses "es gibt noch etwas zwischen den beiden Extremen" ist etwas, was mir in der Diskussion um Design-Patterns zu oft fehlt, wo allzu oft gesagt wird, man solle unbedingt dieses und jenes Pattern einsetzen, ohne überhaupt einmal auf den Anwendungsfall geschaut zu haben.

[@MrLight_001]

Mal eine kleine Frage: Kann man die verschiedenen Sortieralgorithmen, wie quicksort, bubblesort, usw, auch als (behave-) Design-Patterns betrachten (unabhängig von der Sprache)?

[@thenativeweb]

[gr] IMHO nein, weil es eben konkrete Algorithmen sind, und keine Patterns.

[@MrLight_001]

@@thenativeweb Verstehe. Nun ja, ein Algorithmus ist (laut Wikipedia:) Rechenvorgang nach einem bestimmten [sich wiederholenden] Schema. Und ein (Design-)Pattern beschreibst Du als eine Lösungs-Schablone. Man kann auch sagen Muster. - Schema - Schablone - Muster Nun ja, jedem Muster unterliegt auch ein Schema, ob nun auch jedes Schema auch ein Muster ist, das weiß ich noch nicht genau. Aber Du musst doch zugeben, runtergebrochen, sind die Begrifflichkeiten sehr nah beieinander...

[@thenativeweb]

[gr] Ja, die beiden Begriffe liegen beieinander, sind aber nicht deckungsgleich: der Unterschied ist meiner Meinung nach, dass ein Algorithmus konkrete Schritte für ein konkretes Problem beschreibt, wohingegen ein Entwurfsmuster eine allgemeine Richtlinie ist, wie man ein abstraktes Problem angehen kann.

[@micknamens8659]

@@thenativeweb Es gibt schon abstrakte Lösungsmuster, z.B. "Zerlegen in Teilaufgaben" bei quicksort, "Lokale Lösung iterieren" bei bubblesort. Eine interessante Strategie ist radix sort.

[@yutubl]

Meiner Meinung nach enthält überhaupt jede reale Softwarelösung Design-Patterns. Es gibt gar keine Softwarelösung ohne irgendwelche Design-Patterns, so wie es keine Software ohne Programmcode gibt. Es gibt allerdings nicht nur die hier genannten gut gemeinten Design-Patterns, die richtig eingesetzt tolle Ergebnisse bringen aber wie alles im Leben auch unangemessen / unpassend verwendbar sind. Sondern es gibt auch als schlechte Design-Patterns die sogenannten "Anti-Patterns" auf allen Ebenen: Planung = Architekturpatterns, Entwurf und Softwareentwicklung auf Programmcodeebene "Codegeruch" (Code Smell). Die Gang of Four prägten den Begriff und veröffentlichten einen Katalog wichtiger Design-Pattern-Design in C++, Entwurfsmuster ohne diese Bezeichnung gab es vorher. Selbstverständlich sind sinnvolle/angemessen nutzbare Design-Patterns abh. v. d. Kombinationen von Programmiersprache mit ihren Konzepten (statische vs. dynamische Typen), Programmierbibliothek, Framework, weil diese bereits Design-Patterns selbst implementiert haben und man diese bei deren Benutzung einsetzt und so finden Design-Patterns nicht zuletzt Eingang in jede Projektlösung. Was dem Einen (eher agil Kurzblickenden) zuviel (guter) Entwurfsarbeit ist, fehlt dem Anderen (Zielorientiert Weitvorausschauend Bewertenden) und ist Anzeichen fehlender gemeinsamen Konsens zum Ziel und Lösungsweg. Für regelmäßig gleichartige/genügend ähnlich zu entwickelnde Softwarelösungen wäre daher ein vom jeweiligen Team/Abteilung Katalog denkbar, ob und welche Standards einzuhalten sind. Falls dies unterbleibt oder gar nicht kommuniziert wird, ist es Zufall, ob Kunde/Auftraggeber/Produktowner und Entwicklungsteam/-abteilung, gewünschte Software-Projekt-Lösungen im Zeitrahmen in der Qualität so abliefern, wie erwartet. Mit Glück finden Akzeptanztest/Abnahmetests die eklatanten Lücken bevor es ganz zu spät ist.

[@e11y1985]

Liebe angehende Entwickler, Schüler, Stunden, Azubis. Solltet ihr gerade am lernen der Design-Patterns sein und Probleme haben, last euch von dem Video hier nicht demotivieren. Am Ende des Videos wird zwar gesagt das letztendlich der Missbrauch von DPs zu Problemen führen kann, aber ihr müsst diese lernen den ohne schreibt ihr definitiv schlechten Code. Also bloß NICHT KEINE Design Patterns lernen. Wann es sinnvoll ist diese einzusetzen lernt ihr mit der Zeit & Erfahrung und von euren Mentoren und Team Leads. Das Buch der Big Four ist ein Must Have für jeden Entwickler. Lernt Design Patterns und wie man diese sinnvoll nutzt. @Native Web Ich würde nicht soweit gehen das der Titel ein Klickbait ist, aber er ist dem sehr nahe. Bei so einem Thema solltet ihr die Vorteile und das korrekte einsetzen der Design Patterns deutlich hervorheben. Oder arbeitet lhr lieber an großen Projekte wo jeder Entwickler alles schreibt wie er lustig ist? Das Video sollte heißen "Missbrauch von Design Patterns" oder "Over-Engineertes Scharbanak" . Design Patterns Rulez

[@thenativeweb]

[gr] Danke für Deine ausführliche Antwort. Tatsächlich würde ich dem in vielen Punkten widersprechen, insbesondere dem Satz "Das Buch der Big Four ist ein Must Have für jeden Entwickler." Ja, es gibt Design-Patterns, die man kennen sollte, und die man wirklich regelmäßig braucht. Das sind im Wesentlichen die Factory, der Iterator und der Observer. Alle übrigen sind entweder schädlich (Singleton), schmückendes Beiwerk (wie oft braucht man zB einen Visitor), oder trivial (Facade). Ich würde nicht so weit gehen zu sagen, dass man sich nicht irgendwann damit befassen sollte, aber IMHO bekommen Design-Patterns deutlich zu viel Aufmerksamkeit. Den Fokus sollte man IMHO auf die viel grundlegenderen Konzepte Kopplung und Kohäsion legen, auf die Ausbildung mit Interfaces und Entkopplung, auf Abstraktion und Komposition. Daraus ergibt sich nämlich das meiste (ja, nicht alles), was Design Patterns einem beibringen können, ganz automatisch. Insbesondere, weil 95% der Design-Patterns und vor allem deren Implementierung nur in den C-Sprachen sinnvoll sind. Die Welt besteht aber nicht nur aus C, C++, C# und Java. Funktional zu programmieren lernen, pure Functions zu schreiben, zu lernen wie man testet, hat IMHO einen weitaus größeren Einfluss auf die Fähigkeit, Code sauber strukturieren zu können, als ob ich nun drei Design-Patterns mehr oder weniger kenne. Da kann man aber sicherlich auch durchaus geteilter Meinung sein 😊

[@foo0815]

​@@thenativeweb ​ Als Ergänzung hierzu Peter Norvigs Paper über Design Patterns (leicht zu Googeln) Zwar schon etwas älter, aber immer noch lesenswert, z.B. S.10 Design Patterns in Dylan or Lisp 16 of 23 [Gang of Four] patterns are either invisible or simpler, due to: First-class types (6): Abstract-Factory, Flyweight, Factory-Method, State, Proxy, Chain-Of-Responsibility First-class functions (4): Command, Strategy, Template-Method, Visitor Macros (2): Interpreter, Iterator Method Combination (2): Mediator, Observer Multimethods (1): Builder Modules (1): Facade

[@thenativeweb]

[gr] Peter Norvig ftw 🎉

[@KniKnaKnorke]

@@thenativeweb ich finde man sollte sich trotzdem anschauen und auch verstehen was Design Patterns sind. Denn das lernen der pattern hilft zu verstehen, wie man Probleme in der Entwicklung auf eine smarte Weise lösen kann. Natürlich sein deine genannten Punkte wie Abstraktion usw. Wichtiger. Aber wenn man konkrete Probleme löst, nicht auf abstraktions Ebene, dann denke ich kann es helfen, zu wissen was ein observable pattern ist und was es für Probleme es löst. Man muss sie am Ende nicht anwenden, aber ich glaube es hilft einem seinen eigenen Code zu verbessern

[@thenativeweb]

[gr] Das ist richtig, und generell würde ich sagen: mehr lernen ist nie verkehrt. Im Prinzip ging es nur darum, dass man dem Thema nicht ganz so viel Aufmerksamkeit widmen sollte, wie das oftmals vorgelebt wird

[@NachtmahrNebenan]

Für Java Entwickler: das sicherste Singleton ist ein enum (siehe Effective Java, Joshua Bloch). Allerdings kann man von Kevlin Henny jede Menge l Rants zu Singletons an sich finden.

[@st0ox]

Ernsthafte Frage: Ich hatte in der Vergangenheit bei kleineren Projekten (mit unter 50 Klassen) immer gute Erfahrungen mit dem Composite Pattern gemacht, um eine sogenannte "hat eine" Beziehung zwischen zwei Klassen herzustellen und in manchen Fällen wenn nötig später noch die Struktur auf ein decorator pattern zu erweitern. Im Prinzip hab ich da wo ich die Code Base größtenteils kontrollieren konnte nie "ist eine" Beziehungen (also Vererbung) eingesetzt. Kommt natürlich immer drauf an was man eigentlich erreichen möchte wenn man zwei Objekte miteinander in Beziehung setzt. Nun zu der Frage. Derzeit muss ich beruflich an einer alten Code Base aus den späten 90ern arbeiten, wo alles extrem Hierarchisch mit "ist eine" Beziehungen aufgebaut ist und die neue Anforderung an diese code Base sind weitaus agiler als noch in den 90ern. Viele Funktionen die eigentlich statisch sein könnten verlangen nach der gesamten Struktur der Code Base (mit insgesamt 300 Klassen) um trivialste Funktionalitäten aufrufbar zu machen. Ich überlege derzeit daher wirklich mir die Mühe zu machen die ganzen "ist eine" Beziehungen zu "hat eine" Beziehungen auszutauschen (wo es Sinn macht) und dem ganzen Projekt dabei auch eine viel flachere Hierarchie zu geben. Ich weiß ihr kennt den Code jetzt nicht und ich kann ihn euch auch nicht zeigen, aber haltet ihr den Ansatz generell für eine gute Idee, oder sollte man das ganze vielleicht direkt was funktionaler neu Programmieren und versuchen das meiste auf statische Funktionen umzuschreiben und dann halt die ganze Vererbung erstmal so zu lassen und zu hoffen, dass das Projekt dann agil genug ist. Was mein ich mit den agilen Anforderungen? Diese Software aus den 90ern soll in Zukunft als Kern für ein noch größeres Projekt dienen und es wird bis zu einem gewissen grad auch neue Anforderungen und Änderungswünschen ausgesetzt werden. Also meine Frage ist einfach, was haltet ihr generell von Composite Partnern und im Vergleich dazu stark hierarchisierte Verwendung abstrakter Klassen ohne wirklich nützliche Interfaces? Die Hälfte aller Vererbungen in dem Projekt wurden zur Versionierung der Software selber verwendet (da steht dann sowas wie frontpanel13 was von fronpanel12 erbt und um eine Methode erweitert um Abwärtskompatibilität zu "garantieren"...) weil der Softwarehersteller damals nicht Git kannte oder ein anderes Versionierungstool. Soll ich einfach Kündigen? ^^

[@thenativeweb]

[gr] Das ist ehrlich gesagt schwer zu beurteilen, ohne die konkrete Situation näher zu kennen. Allgemein gesagt habe ich die Erfahrung gemacht, dass ein Rewrite oftmals einfacher, zügiger und zielführender ist als der Versuch, etwas Vorhandenes umzubauen. Das hängt aber von vielen Faktoren ab, wie zB: Gibt es Tests, die garantieren, dass man nicht aus Versehen die Semantik ändert? Hat man ein gutes Verständnis für das, was man da umbaut? …? Dass Vererbung als Ersatz für eine Versionsverwaltung genutzt wurde, ist natürlich schon traurig. Andererseits ist die Frage, wie alt der Code ist (Du hattest die 90er erwähnt, aber ich bin nicht sicher, ob sich das auch auf den Code bezog). Wie gesagt, so pauschal ist das sehr schwer zu beurteilen.

[@st0ox]

@@thenativeweb kleine Triggerwarnung vorweg, wer allergisch auf miserable Softwareentwicklung reagiert sollte lieber jetzt wegsehen. Ja der Code wurde 1998 angefangen zu entwickeln, aber hat dann noch bis 2006 immer wieder mal Updates bekommen. Das meiste wurde aber noch bis 2001 entwickelt. Es handelt sich um C++ Code der ein Mikroskop ansteuert was einem eine Höhenmap zurück gibt. Eigentlich keine allzu komplexe Angelegenheit. Es gibt halt ne Achse, einen Kamera Input, ein bisschen Stage-Electronics und eine LED, aber auch ne ganze Menge mathematische Funktionalitäten für die Berechnung der Höhendaten. Leider ist der Berechnungsteil Closed source und von einer anderen Firma extra custom für dieses Mikroskop entwickelt worden und ich habe keinen Zugriff auf diesen Code (die Firma gibt es nichtmehr dazu gleich mehr und auch das Mikroskop selber ist von einer anderen Firma als für die ich arbeite). Das Problem ist, dass dieses Mikroskop nun in einer Maschinenanlage die wir vertreiben vollautomatisch eingesetzt werden soll und daher aus einer C# Software heraus, die die Maschinenanlage bedient, verwendet werden soll. Dafür habe ich mit C++/CLI das ganze C++ Projekt (also den Teil wovon ich den source code hatte) gewrapped und quasi eine simple API erstellt. Jetzt muss man allerdings dazu sagen, dass es sich bei dem C++ code um ein MFC Projekt handelt, wo Businesslogik und die alte MFC UI nicht voneinander getrennt worden, was eine Entkopplung schwierig macht (die MFC UI soll jetzt abgeschafft und durch die C# UI der Maschinenanlage ersetzt bzw in diese integriert werden). Also es wurde damals einfach die ganze Businesslogik in die MFC UI Klassen reingeschrieben. Die MFC Window handle wird man auch nie ganz los werden können, denn an denen hängt die ganze Datenhaltung und diese gehen in die closed source dlls von dem Mathematischen Backend. Es ist also völlig unmöglich das Projekt einfach neu zu machen (es sei denn man reversed engineered den closed source teil, was vermutlich nicht legal ist). Lebenserhaltene Maßnahmen sind also der einzige Weg. Und da das schlimmste an dem ganzen Projekt der MFC/Businesslogik Mischmasch ist wo alles irgendwie von einem CWnd erbt, wäre mein Ansatz mit Umbau Maßnahmen anzufangen. Da eine flachere Hierarchie (womöglich mit Composite Pattern) reinzubringen wäre auch für die Modulare Testbarkeit und Fehlersuche von Vorteil. Tests gab es auch nicht, aber diese konnte ich zu einem gewissen Grad selber erstellen indem ich die Hardware angeschlossen habe und mit Comport-Sniffern und Wireschark den Datentransfer ausgelesen habe (gibt verschiedene Anschlüsse über die verschiedene Funktionalitäten laufen) und gegen diese Input und Rückgabewerte habe ich Unit-Tests und End-to-End tests erstellt. Ich hab auch Tests geschrieben zwischen dem mathematischen Backend soweit es irgendwie ging. Das Mikroskop ist inzwischen auch schon verwendbar aus dem C# der Software, aber es gibt Performance Bugs, diverse crashes und memory leaks, daher die Idee größere Umstrukturierungen an der C++ Code Base vorzunehmen und soweit es geht auch MFC zu eliminieren. Ich habe nichts gegen MFC, aber der Teil wurde einfach unsauber programmiert. Im Prinzip kann man also jetzt anfangen zu arbeiten wo man Seiteneffekte bei Änderungen feststellen kann. Die ganzen Tests zu schreiben und den C# wrapper zu erstellen hat mich 8 Monate gekostet (Mir wurden von der Geschäftsführung aus nur 2 Monate damals eingeplant) und ich müsste lügen, dass es in Deutschland in anderen Hardwarebereichen im Maschinenbau besser aussieht. Man hatte im Maschinenbau halt wirklich in den 90ern geglaubt man müsste jetzt einmal Software als Monolithen entwickeln (oder entwickeln lassen) und danach braucht man so gut wie keine Softwareentwicklung mehr. Daher hatte man bis in die 2010er geglaubt man bräuchte keine guten Softwareabteilungen kultivieren und alles was man mal im eigenen Haus an Softwareentwicklung hatte (als dann die ersten Projekte fertig wurden) soweit es geht nach Osteuropa Indien und Südostasien outgesourced, wobei Deutsche Beraterfirmen die Kommunikation und Zertifizierung dieser Softwarekatastrophen übernommen haben. Und eben genau so eine Beraterfirma hatte das mathematische Backend entwickeln lassen und sich selber den source code nie aus Asien schicken lassen (weil es damals 3000€ mehr gekostet hätte) und diese Beraterfirma existiert auch nicht mehr. Ich bin selber wegen diesem Projekt in die Kritik gekommen (also ich bin neu in der Firma und hatte mit den Entscheidungen in den 90ern nichts zu tun), weil die Entwicklungszeit inzwischen viermal so lange gedauert hat wie von der Geschäftsführung eingeplant, aber entlassen wurde ich nicht, weil es einfach keinen anderen gibt der sowas machen möchte (für das Gehalt was ich bekomme auf dem derzeitigen Arbeitsmarkt). Warum kauft man nicht einfach ein neueres Mikroskop mit einer "echten" modernen API? Diese Mikroskope sind teuer und die Firma hat bereits einige davon gekauft und schon in Anlagen bei Kunden eingebaut. Der Grund so ein altes Mikroskop zu kaufen und nicht ein modernes (z.b. von einem Südkoreanischen Hersteller, da würden mir ein paar einfallen die Softwareseitig um Lichtjahre besser sind) ist, man wollte den heimischen Markt unterstützen (und man hatte ja vorher schon mit dem Hersteller des Mirkoskops zu tun) und diese Mikroskope waren um 10% billiger als die von der Konkurrenz. In diese Kaufentscheidung wurde die Softwareabteilung nicht mit einbezogen. Ich kann jedem nur empfehlen in die Robotik und nicht in den Maschinenbau zu gehen, wenn er sich für Hardwarenahe Entwicklung interessiert, denn ich sehe nicht wie der deutsche Maschinenbau die Kurve mit der Digitalisierung hinbekommen soll.

[@thenativeweb]

[gr] Auch wenn ich leider nicht allzu viel dazu sagen kann, fand ich es extrem spannend, das zu lesen. Vielen Dank für diesen ausführlichen Einblick 😊

[@st0ox]

@@thenativeweb immer gerne. War auf jedenfall sehr therapeutisch das mal los zu werden. Danke fürs Zuhören

[@garytunnicliff3649]

Good content useful discussion on anti-patterns - code smells

[@thenativeweb]

[gr] Thanks a lot 😊

[@papacktrue]

Hallo Golo. Vielen Dank für das super Video :).. nehmen wir mal an es gibt ein react Frontend das per WebSockets mit dem Backend verbunden ist. Das Backend sendet "live" Daten an die verbundenen Frontends (z.B. Produzierte Stückzahl, konkret geht es um eine Maschinenvisualisierung..) Aktuell ist diese Anbindung im Frontend mit einem Singleton gelöst. Das fand ich eigentlich immer ganz gut. Das Singleton ist noch mal von einem hook umschlossen. So kann man die Daten einfach in jeder Komponente verwenden und es gibt immer nur eine websocket Verbindung. Als Benutzer des hooks bekommt man im Ergebnis einfach die Daten und muss sich keine Gedanken machen "wo die herkommen" hättest du das irgendwie anders gelöst?

[@thenativeweb]

[gr] Das mit dem Hook ist, denke ich, schon durchaus der richtige Ansatz. Das hätte ich wahrscheinlich ebenfalls so gelöst. Allerdings ist die Frage, wie ihr das Singleton implementiert habt?

[@papacktrue]

@@thenativeweb wir haben mit typescript eine Singelton Klasse gemacht. Mit typescript ging das, weil man da ja "static" klassenvariablen verwenden kann. Sobald der Hook verwendet wird, holt er sich die instanz des Singelton und es gibt nur eine Websocket Verbindung. Aber Irgendwie fühlt es sich so an, als könnte man das besser lösen.

[@thenativeweb]

[gr] ja, das geht meiner Meinung nach einfacher: ich persönlich würde das Objekt, was es nur einmal geben soll, direkt als Literal definieren, und zwar außerhalb des Hooks. Damit greift der Hook jedes Mal auf die selbe Instanz zu, aber man spart sich den ganzen Aufwand, die Logik für das Singleton in einer Klasse implementieren zu müssen. Theoretisch kann man natürlich immer noch eine Klasse dafür definieren, wenn das zum Beispiel für das testen sinnvoll ist, aber es wäre prinzipiell nicht notwendig. So oder so kann man sich aber die Logik mit dem Singleton an sich sparen.

[@papacktrue]

@@thenativeweb vielen Dank :) das muss ich mal probieren

[@papacktrue]

@@thenativeweb wir haben jetzt alle Singletons entfernt und aus der Klasse einen hook gemacht. Wie du es beschrieben hast. Ohne den ganzen Boilerplate code ist es nun viel verständlicher und der Code hat nur noch wenige Zeilen. Wollte nur nochmal Danke sagen :)

[@dermuschelschluerfer]

Ich komme mit tdd, mvc für frontend/guis und factory und clean code architecture für backends gut zurecht. Man darf nicht alles direkt kopieren, lediglich die grund ideen aufsaugen.

[@omerg3626]

Beim verwenden von pattern kommt es auf den Nutzen an. Man ließt sich die patterns zuvor durch und gleicht es mit der zu lösenden Aufgabe ab. Wenn es das löst dann kann man es anwenden, aber manche patterns führen zum schweren Verständnis des Codes, weil man mehrere Aufrufe macht und tendenziell mehr Klassen verwendet. Nutzen können sein z. B die Performance und die wartbarkeit. Auf jeden Fall solltet ihr die Architektur entscheidung greifbar nahe am Code festhalten oder verlinken. Haltet ruhig den Kontext unter der die Entscheidung gefällt worden ist fest. Kennt ihr Architektur decision record?

[@daw2653]

Liebe native web GmbH, seit circa einem Jahr schaue ich eure Videos mit Faszination zu. Obwohl mein Background momentan in Machine Learning bzw. Deep Learning ist, würde ich mich gerne bei euch bewerben. Habt ihr momentan vakante Stellen frei? Was die Einarbeitung betrifft bin ich sehr fleißig und strebsam. Viele Grüße Dominik

[@thenativeweb]

[gr] Danke für Deine nette Anfrage - magst Du Dich mal bei uns per E-Mail unter hello (at) thenativeweb (dot) io melden?

[@iham1313]

für mich ist vollkommen klar, dass patterns kein allheilmittel sind sondern denkansätze sind. in der objektorientierung für objektorientierung - je nach sprache in der containerisierung für container - je nach umgebung in der netzwerktechnik für netzwerktechnik - je nach netzwerk etc - es gab nie simple antworten auf komplexe fragen; das macht aber weder die frage noch die antwort "falsch". warum - wer auch immer - darauf steht, möglichst viele zu verwenden, erschliesst sich mir nicht. letztendlich sind alle patterns da um ein spezifisches aber abstraktes problem zu lösen - wer das problem nicht hat, braucht also auch keine lösung dafür

[@thenativeweb]

[gr] Ja, das stimmt … und "letztendlich sind alle patterns da um ein spezifisches aber abstraktes problem zu lösen" fasst es ganz gut zusammen 😊

[@DJTechnostyler]

Ich gebe zu, dass ich Singleton nutze. Aber nur, wenn ich etwas wirklich ständig brauche, wie z.B. den aktuellen Nutzer im Frontend. Den überall mit durchzureichen wäre ein Albtraum. Wo ich das noch ganz gerne nutze ist z.B. bei einem Store oder einer Netzwerkanbindung. Ansonsten nutze ich sehr gerne den decorator, den visitor, den iterator und den observer. Factory ist auch ab und an mal sehr praktisch, wenn man z.B. eine Komponente anhand eines Typs erstellen will. Also boolean => checkbox, string => text, string[] => select. Alle anderen Patterns finde ich eher nicht so hilfreich und sehr viele sogar eher hinderlich aus den von dir genannten Gründen.

[@thenativeweb]

[gr] Danke für Deine Einschätzung und Deinen Erfahrungsbericht. Ja, das mit dem Nutzer kann ich verstehen … das ist ja auch so ein typisches Szenario, was in React zum Beispiel per Kontext gelöst wird, was letztlich auch nichts anderes als eine gekapselte globale Variable ist. Bei all diesen Cross-Cutting-Concerns wird es immer etwas schwierig. Spannend finde ich, dass Du den Visitor erwähnt hast. Gerade für dieses Pattern habe ich (glaube ich) noch nie einen realen Anwendungsfall gesehen. Mag aber auch an der Art der Themen liegen, mit denen man so zu tun hat. Wenn ich fragen darf - wofür verwendest Du den?

[@DJTechnostyler]

@@thenativeweb selbstverständlich darfst du fragen ;) Ich habe mit sehr großen Objekten zu tun, bei denen ich die einzelnen Felder ständig rekursiv prüfen muss. Dabei muss ich dann meistens bis zu den Blättern der Bäume, die durch die Objektstruktur entstehen. Ab und an aber auch mal zwischen drin irgendwelche intermediate knoten. Da bietet es sich an einfach mal zu jedem knoten zu gehen und zu prüfen, ob denn das ein Knoten ist, den ich brauche. Das Visitor-Pattern bietet sich aber auch echt nur bei tiefen Strukturen an. Wenn du sowas auch mal brauchst, kann ich dir deepdash empfehlen. // Edit Damit es vielleicht noch etwas verständlicher wird... Die großen Strukturen werden damit alle komprimiert. Damit ich aber nicht für jede Struktur einen eigenen Kompressor schreiben muss, schiebe ich das einfach in meinen Visitor und kann dann die Formate entsprechend zentral überführen.

[@thenativeweb]

[gr] Danke für die Erklärung - dafür passt es tatsächlich sehr gut, das ist allerdings auch schon relativ speziell (würde ich mal behaupten). Aber wie gesagt, dafür passt es 1a 😊

[@thenativeweb]

[gr] Danke für die Erklärung - dafür passt es tatsächlich sehr gut, das ist allerdings auch schon relativ speziell (würde ich mal behaupten). Aber wie gesagt, dafür passt es 1a 😊

[@nudoduno8081]

Mal ne Frage: Sollten in z.b. React eigenen Componenten die Intention über den Namen verraten? Oder rein ein funktionsbeschreibender Name?

[@thenativeweb]

[gr] Ich bin mir nicht ganz sicher, ob ich deine Frage richtig verstanden habe. Kannst du eventuell mal ein Beispiel nennen?

[@S3R43o3]

Hab bisher noch nie in nem Team gerabeitet. Würde ich tatsächlich gerne mal. Ich versuche etwas mit Patterns zu arbeiten, denke aber da der meiste Code eh nur von mir selbst genutzt wird geht das immer ein bisschen unter =D

[@thenativeweb]

[gr] Vielleicht ergibt sich das ja einmal, es ändert auf jeden Fall vieles, zumindest, wenn man im Team auch gemeinsam arbeitet und nicht nur jede:r vor sich hin werkelt.

[@S3R43o3]

@@thenativeweb Vielen vielen Dank das ihr euch immer wieder die Mühe macht zu antworten =) Joah ich denke das tut der Motivation auch was gutes ^^ Ganz zu schweigen von dem was man von anderen lernen kann.

[@thenativeweb]

@@S3R43o3 [gr] Naja, wir versuchen es zumindest 😊 Allerdings wird es zunehmend schwieriger, alles mitzubekommen, insofern wird's sicherlich auch mal den ein oder anderen Kommentar geben, den wir übersehen. Das ist dann aber keine Absicht.

[@MrSnuffyX]

Keine Design-Patterns sind auch keine Lösung.

[@thenativeweb]

[gr] Das ist richtig, das war aber auch nicht der Vorschlag 😉

[@MrFrankie180]

Generell ist die lose Koppelung das einzige was für mich heute noch zählt. Dafür braucht man gar kein Pattern nur ein mindset. Ich mach das über JS multiple inheritance im Frontend. Damit trenne ich die behavior vom business process code.

[@NachtmahrNebenan]

Patterns sind Konzepte und ab da sollte man konzeptionell denken und nicht in Patterns. Venkat Subramaniam hat schöne Talks zu Functional Programming gemacht und wie sich dort Patterns übertragen lassen. Danach vergisst man die Patterns und freut sich über das injizieren von Verhalten als Parameter 😄

[@conqirich5705]

Ich verwende gerne Strategie Pattern um den Code erweitern zu können und den Code besser aufzuteilen oder zu strukturieren

[@thenativeweb]

[gr] Das ist ja auch völlig in Ordnung - mir ging es ja auch nicht darum, von Design-Patterns generell abzuraten, sondern darauf hinzuweisen, dass man sie nur dort einsetzen sollte, wo sie auch sinnvoll und angebracht sind. Und das tust Du dann ja vermutlich 😊

[@marcusreinicke]

Ohjeee Golo. Wir sind mal wieder an dem Punkt angekommen. Der Krieg zwischen den Sprachen. Ich hab mit meiner Sprache den Längeren😂🤣 Die Nähe zur OOP ist doch logisch. Wurde sie auch als das Mittel schlecht hin dahingestellt. Aber OOP hat seine Berechtigung und ist auch die verbreitetste Programmierart. Und ja ich finde es richtig und klasse. Denn prozeduralen Code - nein Danke, das geht gar nicht mehr. Ich arbeite gerade mit Code, in dem Memberfunktionen mit 500 Zeilen klein sind die Minderheit darstellen. Alle anderen haben 800 / 1000 und mehr Codezeilen.😳😒 Da würdest Du Dir nach Patterns zum einarbeiten, die Finger lecken 😏 Du spricht von gut lesbaren Code, nimmst im gleichen Moment aber JavaScript in den Mund. Ja kann man. Aber Du willst mir nicht erklären, dass die Hybriden Typen in JavaScript den Code leserlicher machen. Keine Typisierung. Sorry nein. Kann sein, dass es Vorteile gibt, die Nachteile überwiegen meiner Meinung aber. Wenn Du mal kein Intellisense haben solltest, sind das genau solche Elemente die den Code sehr unleserlich machen. Warum gibt es Typescript? Um u.a. eine gewisse Typsicherheit nachträglich einbauen zu können. JS ist ja wie der Name sagt eine Scriptsprache. Aber lassen wir das an der Stelle, denn da sind wir bei dem Punkt. Welche Sprache die bessere ist. Du suggerierst mit den Titel und mit einigen Aussagen, dass DP, überflüssig, gar störend und den Code unleserlicher machen. Au contraire mon Capitan. 😉(hab ich’s richtig geschrieben? Ach egal😉) Du vermittelst das in einer Art und Weise an nachfolgende Generationen von Entwicklern. Find ich nicht gut. Du sprichst einen wesentlichen Punkt an, erteilst ihn aber nicht die Tragfähigkeit, die er verdient. Die Kommunikation. Es ist nunmal Fachsprache. Diese sollte ein Fachmann auch kennen. Denn es ist nun mal so, dass durch das Wissen über DP eine einheitliche Sprache gesprochen werden kann. Und das kann ein extrem wichtiger Punkt sein, wenn man sich versteht. Was sind DP? Vor Jahren haben wir Teile davon verwendet, da gab es das Wort bzw. die Empfehlungen noch gar nicht. Auch falsch, sagen wir mal so, es gab das schon aber DP waren nicht so verbreitet. Es kam bei uns erst später auf, wie SOLID und die anderen Prinzipien. Sind sie deshalb falsch? Nein, nur man muss wissen was man tut. Singleton ist ein AntiPattern. Es kann mehr Schaden anrichten, als beseitigen, nur allein dadurch, dass in der Zukunft, nicht nur eine Instanz einer Klasse geben muss. Dann ist die Heulerei und der Umbau groß. Also man muss wissen was man tut. Und Nein, es geht nicht darum dass ein Code nur gut ist, der Patterns enthält, wer das denkt, sollte vielleicht, nochmal ein paar Bücher wälzen Du hast recht. Es geht um Entkopplung. Und viele Pattern ähneln sich. Das liegt in der Natur der Sache. Es geht um Struktur, aber gerade dass ist es doch, was gerade gerade brauchen. Zumindest die Entkopplung. Struktur war schon immer ein Thema. Viele DP sind auch aufgestiegen zu AP Architektur Pattern. Dadurch ist SaaS und Co. erst sauber möglich. Durch saubere Verträge(Contracts), die definieren, wie man Daten austauscht. Und das in einer einheitlichen Sprache. Ob als Hintergrunddienst, Webservice, MessageQueue Anbindung, sockets, egal Viele benutzen Pattern und wissen es gar nicht, was traurig ist, denn soweit ich weiß, gibt es einige, die den z.B. von Dir angesprochenen Iterator auch ein DP ist nicht als solchen kennen. Es ist nur so übergegangen, dass es einfach so benutzt wird. Man sollte DPˋs nicht einfach so als absurdum abtun. Und klar, es gibt sie immer wieder, Sprachen, wo DP keinen Sinn machen. Gerade bei Scripte. Aber wie Du schon sagst, in der OOP Welt, sollten sie zumindest beherrscht werden. Aber was ist falsch daran, das StrategiePattern oder das Repository Pattern zu nutzen, auf Hinblick der Entkopplung, des Testens und des Mockens? Natürlich kann man es mit DP auch übertreiben, aber für viele Prinzipien, wie SOLID sind Pattern eine extrem große Hilfe. CleanCode Vorschläge, Ja, lass sie mich mal Vorschläge nennen, zeigen auch hin auf Pattern wie IoC z.B. Und natürlich ist es so, aber ohne Dependency Injection würde es viele Pattern gar nicht erst geben. Wie das Strategy z.B. Ohne Polymorphy kein Dependency Injection. Also bitte, verteufel Pattern nicht einfach so, nur weil Du im Moment mit Sprachen hantierst, wo aus syntaktischem Grund, DPˋs keinen Sinn ergeben, oder gar anwendbar sind.. 😉 LG Marcus P.S: Wer Rechtschreibfehler finden sollte, darf sie behalten.😊👍

[@silentwater79]

@@marcusreinicke Es ist nichts falsch daran. Das Problem ist, das diese inflationär für alles verwendet werden nach dem Motto viel hilft viel und man vor lauter Designpatterns und unnötigen Abstraktionebenen den eigentlichen Zweck des Codes aus dem Auge verliert und man sich teils erst durch zig Abstraktionebenen hangeln muß, bis man zu dem Code kommt er wirklich was tut. Es geht eher darum, zu wissen wann man es Nutzt und wann es mit Kanonen auf Spatzen geschossen ist.

[@marcusreinicke]

@@silentwater79 natürlich, wie geschrieben, zuviel ist nicht gut. Aber grundsätzlich falsch sind DP nicht, aber genau das suggeriert aber das Video teilweise. Wie gesagt sind viele Prinzipien der Softwareentwicklung ohne Pattern nicht mehr möglich. Aber man kann auch alle Pinzipien verteufeln, da viele derer, mehrareit bedeuten😉

[@Massenhaft1]

Der Vergleich Singelton (1997) vs Dependency Injection (2004) ist unfair :). Wer also weiter lernt, wird das Problem hoffentlich erkennen.

[@thenativeweb]

[gr] Und warum findest Du den Vergleich unfair? Weil zwischen dem Singleton und dem Konzept der Dependency Injection sieben Jahre liegen?

[@Massenhaft1]

@@thenativeweb Weil es 1997 sicher eine sehr gute Idee war (Rechner langsamer, wenig RAM, viele Fat-Client Projekte, Immutability zu teuer usw.). Ein paar Jahre später gibt es halt neue Ideen in einem anderen Kontext.

[@thenativeweb]

[gr] Das ist richtig, trotzdem hätte man darauf hinweisen können, dass das Singleton nicht das Nonplusultra ist, und es nicht so darstellen, als ob es eine tolle Lösung für ein bestimmtes Problem wäre. Denn das ist keine tolle Lösung ist, das war auch 1997 schon absehbar, da es zu einer extrem hohen Kopplung führt.

[@UllrichPraetz]

Tatsächlich. Design Patterns werden ohne Not übermäßig oft verwendet.

[@thenativeweb]

[gr] Danke für Deinen Kommentar 😊

[@Paul-kr8dq]

Naja... Zu wissen, ob ein DP in einem bestimmten Kontext überhaupt anwendbar ist und welche Konsequenzen das mit sich bringt bedeutet erst, DP verstanden zu haben. Bis dato bleibtst du halt jemand, der "darüber schon mal gehört hat" 😂 Ich würde daraus allerdings nicht pauschal ableiten, dass man sie etwa nicht mehr lernen oder anwenden soll. Ein Softwareingenieur, der behauptet, keine DP zu kennen "weil sie nicht mehr relevant sind" wirkt auf mich vergleichbar leiderregend, wie etwa ein Handwerker, der keine Zange bedienen kann, weil "man heutzutage mit dem elektrischen Werkzeug arbeitet" 🤷🏻‍♂️

[@2teKnoA]

Entweder hat die Kamera oder der Encoder ein kleines Problem mit deinen farbaenderden Kacheln. Die weisse Flaeche daneben aendert staendig ihren Grauwert. :)

[@foo0815]

Nach langjähriger Entwicklererfahrung ist es bei mir inzwischen ein Reflex geworden, beim Begriff "Design Pattern" sofort an "Cargo cult programming" zu denken... ;-)

[@thenativeweb]

[gr] Den Begriff kannte ich zwar schon, aber in dem Kontext hatte ich bislang nicht daran gedacht - aber ja, hat was 😊

[@TheOnlyDominik]

Ja zu MVC, MVVM und "I love it" Ctor-Dependency Injection und Singleton, Iterator, ... Aber mit diesen abstrakten Schwurbel-Pattern kann ich nix anfangen. Ich kenne nur Leute, die sich selbst beweihräuchern wollen, die diese verwenden. Die meinen dann tatsächlich, dass deren Code wartungsfreundlich ist, ist er aber auf keinen Fall. Software ist ein Wegwerfartikel, lieber schnell eine neue App bauen, als wochenlang in alten Code einarbeiten, um zu verstehen was sich der Entwickler dabei gedacht hat. KISS - Keep it simple and stupid.

[@thenativeweb]

[gr] Das finde ich einen ganz wichtigen Punkt: man sollte versuchen, Software in kleine Einheiten zu zerlegen, die man - genau wie du sagst - im Zweifelsfall mit überschaubarem Aufwand neu schreiben und ersetzen kann. Das geht tatsächlich oftmals viel schneller, als zu versuchen, in einer großen, komplexen Software einen Fehler zu finden und zu beheben oder sie zu erweitern. Natürlich heißt das nicht, dass man niemals auf Fehlersuche gehen sollte oder niemals versuchen sollte, ein Feature einzubauen. Aber es sollte zumindest eine Option sein, und zwar keine völlig abwegige.

[@tomhoffmann6233]

Ich finde SOLID viel schöner

[@cdoubleplusgood]

Das sind Principles, keine Patterns. Ja, beides greift oft ineinander. SOLID sind jedenfalls nicht die besseren "Patterns", SOLID kann z.T. mit Hilfe von Patterns umgesetzt werden.