Bestimmte Patterns zu erlauben bzw. zu verbieten halte ich für kontraproduktiv. Ein guter Entwickler sollte die freie Wahl haben, wann er welches Pattern (oder eine andere Lösung) einsetzt. Den Einsatz von Design Pattern zu restriktieren, erzeugt mehr Probleme als Vorteile und schränkt Entwickler unnötig ein. Viel mehr sollte darauf geachtet werden, dass alle Entwickler im Team einen gewissen Kenntnisstand haben, so dass qualitativ gute Softwareentwicklung möglich ist. Und dazu gehört auch, das Design Patterns nicht inflationär genutzt werden. Das mit "Verboten" bzw. Richtlinien zu forcieren, führt meiner Meinung nach nicht zum gewünschten Ziel. Viel eher sorgt es dafür, dass Entwickler die Motivation verlieren, weil es erstmal Diskussionen gibt, wenn ein bestimmtes Pattern genutzt werden soll, welches nicht erlaubt ist. Diesen Aufwand würde ich mir z.B. nicht antun, sondern auf den Einsatz des Design Patterns verzichten und dabei dann unter Umständen gewzungen sein, Code zu schreiben, der auch nicht dem KISS-Prinzip entspricht, womit die Restriktion der Design Patterns wieder nach hinten losgeht. Ich mag deine Videos, aber dieses Mal bin ich gänzlich anderer Meinung als du.
I habe nie verstanden wie man bei pattern “pivoted”. Ganz agil ändern meine Auftraggeber dauernd die Anforderungen. Dann muss man bei SharePoint plötzlich von einem „Feature“ zu einem anderen springen. Alles refaktorieren.
Design-Pattern sind Werkzeuge. Wie in dem Video über schädliche Werkzeuge gilt auch hier, man sollte das Werkzeug einsetzen, wenn es ein gegebenes Problem löst, nicht weil man immer schon mal damit arbeiten wollte. Und wenn sie dieses Problem dann lösen, dann ist es auch richtig, sie zu nutzen, denn dann sind sie Teil des KISS. Denn ohne das Pattern hätte man einen wildwuchs, der noch schwerer zu erarbeiten ist, als ohne. Meine 0.02€.
Interessant, meine Erfahrung ist genau das Gegenteil: Die wenigsten Programmierer, selbst die Erfahrenen, kennen die gängigen design patterns, und lehnen es auch ab, sie zu lernen. Dennoch werden sie ständig genutzt - unabsichtlich, weil sauberer Code einfach häufig zur Anwendung von Patterns führt. Der Haupt Unterschied ist wohl, das bei Programmierern die Design Patterns kennen, die Klassen dann wirklich XYZAdapter, XYZDecorator, XYZFascade, XYZBuilder benamt werden, oder zumindest in den Comments darauf hingewiesen wird. Bei guten Entwicklern , die Design Patterns ablehnen, die machen dann genau das selbe, nur heisst die Klasse dann XYZWrapper, und man muss sich erst einlesen um raus zu finden was das Ding eigentlich macht.
MVVM ist eine gute Idee um durch Trennung der Datenhaltung von der jeweiligen Ausgabe die Austauschbarkeit der Komponenten zu erhöhen. Das ist m.E. nach sinnvoll investierte Zeit.
Richtlinien festzulegen finde ich generell gute Idee. Mittlerweile gibt es so viele verschiedene Desing-Patterns, sodass es nicht mehr möglich ist alle zu lernen geschweige überhaupt zu kennen. Wie ich zum ersten Mal nach Design-Pattern recherchiert habe, gab es irgendwie nur 4 verschiedene. Vor ein paar Jahren waren es schon viel mehr. Heute ist die Liste ellenlang. Design-Pattern können KISS-Konform sein.
"Entwurfsmuster. Elemente wiederverwendbarer objektorientierter Software ist ein 1994 von Erich Gamma, Richard Helm, Ralph Johnson und John Vlissides herausgegebenes Buch über wiederverwendbare Entwurfsmuster und gilt als eines der Standardwerke im Bereich Softwaretechnik." Darin werden 23 Muster erwähnt.
Unterschreib ich so. Ein Kollege hat neulich eine größere Komponente mit „für leichtere Erweiterbarkeit und Wiederverwendbarkeit“ mit Interfaces, C++ Template-Methoden und Vererbung vollgepflastert und jetzt will niemand sonst mehr diesen Code anfassen. Weil man jedes Mal wenn man in die Komponente schaut erst 10 Minuten überlegen muss, wie das jetzt nochmal strukturiert ist und wo überhaupt die effektive Implementierung versteckt ist. Also ist jetzt „hochelegant“ aber völlig spaßbefreit zu pflegen. Hurra?
bissl o.t.: KISS hab ich immer spo verstanden: keep it simple, stupid! Oder auf deutsch: Ich hab gesagt du sollst es einfach halten, du Idiot! p.s.: danke für deine Inputs!!
So ist es!!! "Keep it simple, stupid!" besagt, dass eine Problemlösung eben deshalb stupid ist, weil sie NICHT simple ist (oder zumindest so simple wie möglich). "Keep it simple and stupid." verkehrt diese Aussage in ihr Gegenteil. Wer das nicht versteht, disqualifiziert sich als Softwareentwickler selbst! Sorry, das klingt harsch, aber ich höre die falsche Version leider sehr oft und es triggert mich jedesmal extrem.
@DavidTielke Das von dir erwähnte Singleton-Pattern ist bei Entwickler allgemein als Anti-Pattern bekannt und sollte daher in jeder Richtlinie verboten sein. In jeder Anwendung gleich welcher Art hat man ja ein festen Startpunkt. In den C-Dialekten und auch in Java ist das die Mainmethode. Benötigt man also ein einziges Objekt zur gesamten Laufzeit, so wäre dort der richtige Platz dies zu erzeugen und mittels DI in die Objekte zu schieben, die diese benötigen. Dazu gab es m.W. nach auch schon ein Video von dir. Ich sehe den Einsatz von Patterns genauso wie Frameworks, Programmiersprachen / -techniken. Zuerst prüfen, welche Vor- / Nachteile der Einsatz bringt und basierend auf dieser Abwägung entscheiden. In dem Zusammenhang habe ich bei Stackoverflow gelesen, dass einige meiner Kollegen den Einsatz von statischen Funktionen verteufeln, andere von guten / bösen statischen Methoden sprechen. Ich halte solche Pauschalisierungen für recht fragil ohne einen konkreten Kontext. Man sollte halt wissen was man tut, sonst sollte man es besser lassen. Diesen vielleicht recht strikten Leitsatz kann man in allen Lebensbereichen anwenden, nicht nur in der Softwareentwicklung.
Ich würde Singleton nicht pauschal als Antipattern bezeichnen. Es wird nur leider oft unnötigerweise verwendet. Aber gezielt eingesetzt, z.B. bei Caches, ist es sinnvoll.
@@stefankahnert9632 Ja, das hat David ja auch im Video erwähnt, dass man durch Kenntnis eines Patterns es quasi überall einsetzt unabhängig ob nötig oder nicht. Habe es selbst lange Zeit eingesetzt. Das Pattern hat allerdings das Problem, dass es wie alle statischen Methoden nur schwer automatisiert getestet werden kann. Das sollte demjenigen bewusst sein. Ob man das Pattern nun so oder so sieht muss jeder selbst entscheiden. Ich werde es jedenfalls nicht mehr einsetzen, da ich das Problem mittels DI genauso gut lösen kann und diese Lösung zudem automatisiert testen kann.
Du widersprichst dir selbst! Einerseits willst du das SIngleton Pattern in jeder Richtline verbieten, einige Sätze später vertrittst du die Meinung, dass man wissen sollte, was man tut. Tja, und wenn ich nun genau weiss, dass ich das Singleton Pattern brauche, es jedoch durch dich verboten wurde, wie passt das dann zusammen? Verbote führen selten zu sinnvollen Ergebnissen.
@@mk1roxxor Das sehe ich nicht so. In den meisten Fällen lässt sich das Ziel des Singletons, nämlich nur eine Instanz des Objekts zur Laufzeit zu haben, genauso gut mit Dependency Injection nutzen. Ich hatte eine Anwendung wo ich die DB-Verbindung mittels Singleton umgesetzt hatte. Nachdem ich von DI erfahren und mich intensiv damit beschäftigt habe, habe ich den Code umgebaut. Nicht nur ist der Code nun leichter zu verstehen, er ist testbar und sogar performanter. Kann natürlich sein, dass Sie einen exotischen Anwendungsfall haben, wo das Problem nur mittels Singleton gelöst werden kann. Aber wie gesagt kann das Singleton i.d.R. problemlos durch DI ersetzt werden. Ist halt Aufwand. Aber wenn man langfristig mit der Softwate arbeiten will, ist DI dem Singleton vorzuziehen. Aber wenn Sie anderer Meinung sind, akzeptiere ich dies.
@@alexanderbehling4680: Mir geht es nicht um Singleton Pattern als solches, sondern um das generelle Verbot von Dingen, die man selbst für nicht sinnvoll erachtet. Das schränkt Entwickler unnötig ein und hat, in den allermeisten Fällen, einen eher negativen Effekt. Wir können uns vom Singleton wegbewegen (es gibt durchaus nicht-exotische Anwendungsfälle für dieses Pattern, das will ich hier aber gar nicht weiter ausführen) und zu den statischen Methoden kommen. Ich halte in OOP von statischen Methoden überhaupt nichts, würde aber nie auf die Idee kommen, eine Richtlinie zu verfassen, die den Einsatz statischer Methoden generell verbietet. Jeder Entwickler sollte genügend Freiraum haben, Dinge so umsetzen, wie er es für sinnvoll erachtet. Dazu gehört aber auch, dass sich Entwickler der Vor- und Nachteile ihrer jeweils genutzten Lösung bewusst sind. Ich habe Restriktionen in Richtlinen, die für mich keinen Sinn ergaben, immer hinterfragt. Kam dann für mich keine zufriedenstellende Antwort, habe ich den Arbeitgeber gewechselt. Heute, viele Jahre später, entwerfe ich solche Richtlinien selbst und vermeide Restriktionen in diesen ganz bewusst, da für mich andere Dinge deutlich wichtiger sind, als den Entwicklern aufzuoktroyieren, was sie zu tun und zu lassen haben. Allerdings sortiere ich in den Bewerbungsgesprächen relativ strikt ungeeignete Kandidaten aus, bei den passenden Bewerbern bin ich mir dann recht sicher, dass sie keine Richtlinien brauchen, die sie unnötig einschränken.
Wie heißt eigentlich das lol.poop().unwrap().nepp("ja").unwrap().wasischnischwasdashiertut('viel spaß damit!'); Pattern? Die schlimmste newskool-Seuche von allen.
Bestimmte Patterns zu erlauben bzw. zu verbieten halte ich für kontraproduktiv. Ein guter Entwickler sollte die freie Wahl haben, wann er welches Pattern (oder eine andere Lösung) einsetzt. Den Einsatz von Design Pattern zu restriktieren, erzeugt mehr Probleme als Vorteile und schränkt Entwickler unnötig ein. Viel mehr sollte darauf geachtet werden, dass alle Entwickler im Team einen gewissen Kenntnisstand haben, so dass qualitativ gute Softwareentwicklung möglich ist. Und dazu gehört auch, das Design Patterns nicht inflationär genutzt werden. Das mit "Verboten" bzw. Richtlinien zu forcieren, führt meiner Meinung nach nicht zum gewünschten Ziel. Viel eher sorgt es dafür, dass Entwickler die Motivation verlieren, weil es erstmal Diskussionen gibt, wenn ein bestimmtes Pattern genutzt werden soll, welches nicht erlaubt ist. Diesen Aufwand würde ich mir z.B. nicht antun, sondern auf den Einsatz des Design Patterns verzichten und dabei dann unter Umständen gewzungen sein, Code zu schreiben, der auch nicht dem KISS-Prinzip entspricht, womit die Restriktion der Design Patterns wieder nach hinten losgeht. Ich mag deine Videos, aber dieses Mal bin ich gänzlich anderer Meinung als du.
I habe nie verstanden wie man bei pattern “pivoted”. Ganz agil ändern meine Auftraggeber dauernd die Anforderungen. Dann muss man bei SharePoint plötzlich von einem „Feature“ zu einem anderen springen. Alles refaktorieren.
Design-Pattern sind Werkzeuge. Wie in dem Video über schädliche Werkzeuge gilt auch hier, man sollte das Werkzeug einsetzen, wenn es ein gegebenes Problem löst, nicht weil man immer schon mal damit arbeiten wollte. Und wenn sie dieses Problem dann lösen, dann ist es auch richtig, sie zu nutzen, denn dann sind sie Teil des KISS. Denn ohne das Pattern hätte man einen wildwuchs, der noch schwerer zu erarbeiten ist, als ohne. Meine 0.02€.
Interessant, meine Erfahrung ist genau das Gegenteil: Die wenigsten Programmierer, selbst die Erfahrenen, kennen die gängigen design patterns, und lehnen es auch ab, sie zu lernen. Dennoch werden sie ständig genutzt - unabsichtlich, weil sauberer Code einfach häufig zur Anwendung von Patterns führt. Der Haupt Unterschied ist wohl, das bei Programmierern die Design Patterns kennen, die Klassen dann wirklich XYZAdapter, XYZDecorator, XYZFascade, XYZBuilder benamt werden, oder zumindest in den Comments darauf hingewiesen wird.
Bei guten Entwicklern , die Design Patterns ablehnen, die machen dann genau das selbe, nur heisst die Klasse dann XYZWrapper, und man muss sich erst einlesen um raus zu finden was das Ding eigentlich macht.
was hälst du von mvvm :)?
MVVM ist eine gute Idee um durch Trennung der Datenhaltung von der jeweiligen Ausgabe die Austauschbarkeit der Komponenten zu erhöhen. Das ist m.E. nach sinnvoll investierte Zeit.
Richtlinien festzulegen finde ich generell gute Idee. Mittlerweile gibt es so viele verschiedene Desing-Patterns, sodass es nicht mehr möglich ist alle zu lernen geschweige überhaupt zu kennen. Wie ich zum ersten Mal nach Design-Pattern recherchiert habe, gab es irgendwie nur 4 verschiedene. Vor ein paar Jahren waren es schon viel mehr. Heute ist die Liste ellenlang.
Design-Pattern können KISS-Konform sein.
"Entwurfsmuster. Elemente wiederverwendbarer objektorientierter Software ist ein 1994 von Erich Gamma, Richard Helm, Ralph Johnson und John Vlissides herausgegebenes Buch über wiederverwendbare Entwurfsmuster und gilt als eines der Standardwerke im Bereich Softwaretechnik." Darin werden 23 Muster erwähnt.
@@steffenhantschel2016er hat bestimmt 1993 recherchiert ;)
Unterschreib ich so.
Ein Kollege hat neulich eine größere Komponente mit „für leichtere Erweiterbarkeit und Wiederverwendbarkeit“ mit Interfaces, C++ Template-Methoden und Vererbung vollgepflastert und jetzt will niemand sonst mehr diesen Code anfassen.
Weil man jedes Mal wenn man in die Komponente schaut erst 10 Minuten überlegen muss, wie das jetzt nochmal strukturiert ist und wo überhaupt die effektive Implementierung versteckt ist.
Also ist jetzt „hochelegant“ aber völlig spaßbefreit zu pflegen.
Hurra?
Super Video. Hab ich direkt nen paar Kollegen geschickt die das sehen müssen 😉
bissl o.t.: KISS hab ich immer spo verstanden: keep it simple, stupid! Oder auf deutsch: Ich hab gesagt du sollst es einfach halten, du Idiot!
p.s.: danke für deine Inputs!!
So ist es!!! "Keep it simple, stupid!" besagt, dass eine Problemlösung eben deshalb stupid ist, weil sie NICHT simple ist (oder zumindest so simple wie möglich). "Keep it simple and stupid." verkehrt diese Aussage in ihr Gegenteil. Wer das nicht versteht, disqualifiziert sich als Softwareentwickler selbst! Sorry, das klingt harsch, aber ich höre die falsche Version leider sehr oft und es triggert mich jedesmal extrem.
@DavidTielke
Das von dir erwähnte Singleton-Pattern ist bei Entwickler allgemein als Anti-Pattern bekannt und sollte daher in jeder Richtlinie verboten sein.
In jeder Anwendung gleich welcher Art hat man ja ein festen Startpunkt. In den C-Dialekten und auch in Java ist das die Mainmethode.
Benötigt man also ein einziges Objekt zur gesamten Laufzeit, so wäre dort der richtige Platz dies zu erzeugen und mittels DI in die Objekte zu schieben, die diese benötigen.
Dazu gab es m.W. nach auch schon ein Video von dir.
Ich sehe den Einsatz von Patterns genauso wie Frameworks, Programmiersprachen / -techniken. Zuerst prüfen, welche Vor- / Nachteile der Einsatz bringt und basierend auf dieser Abwägung entscheiden.
In dem Zusammenhang habe ich bei Stackoverflow gelesen, dass einige meiner Kollegen den Einsatz von statischen Funktionen verteufeln, andere von guten / bösen statischen Methoden sprechen.
Ich halte solche Pauschalisierungen für recht fragil ohne einen konkreten Kontext.
Man sollte halt wissen was man tut, sonst sollte man es besser lassen.
Diesen vielleicht recht strikten Leitsatz kann man in allen Lebensbereichen anwenden, nicht nur in der Softwareentwicklung.
Ich würde Singleton nicht pauschal als Antipattern bezeichnen. Es wird nur leider oft unnötigerweise verwendet. Aber gezielt eingesetzt, z.B. bei Caches, ist es sinnvoll.
@@stefankahnert9632 Ja, das hat David ja auch im Video erwähnt, dass man durch Kenntnis eines Patterns es quasi überall einsetzt unabhängig ob nötig oder nicht. Habe es selbst lange Zeit eingesetzt. Das Pattern hat allerdings das Problem, dass es wie alle statischen Methoden nur schwer automatisiert getestet werden kann.
Das sollte demjenigen bewusst sein. Ob man das Pattern nun so oder so sieht muss jeder selbst entscheiden. Ich werde es jedenfalls nicht mehr einsetzen, da ich das Problem mittels DI genauso gut lösen kann und diese Lösung zudem automatisiert testen kann.
Du widersprichst dir selbst! Einerseits willst du das SIngleton Pattern in jeder Richtline verbieten, einige Sätze später vertrittst du die Meinung, dass man wissen sollte, was man tut. Tja, und wenn ich nun genau weiss, dass ich das Singleton Pattern brauche, es jedoch durch dich verboten wurde, wie passt das dann zusammen? Verbote führen selten zu sinnvollen Ergebnissen.
@@mk1roxxor Das sehe ich nicht so. In den meisten Fällen lässt sich das Ziel des Singletons, nämlich nur eine Instanz des Objekts zur Laufzeit zu haben, genauso gut mit Dependency Injection nutzen. Ich hatte eine Anwendung wo ich die DB-Verbindung mittels Singleton umgesetzt hatte.
Nachdem ich von DI erfahren und mich intensiv damit beschäftigt habe, habe ich den Code umgebaut. Nicht nur ist der Code nun leichter zu verstehen, er ist testbar und sogar performanter.
Kann natürlich sein, dass Sie einen exotischen Anwendungsfall haben, wo das Problem nur mittels Singleton gelöst werden kann. Aber wie gesagt kann das Singleton i.d.R. problemlos durch DI ersetzt werden. Ist halt Aufwand. Aber wenn man langfristig mit der Softwate arbeiten will, ist DI dem Singleton vorzuziehen.
Aber wenn Sie anderer Meinung sind, akzeptiere ich dies.
@@alexanderbehling4680: Mir geht es nicht um Singleton Pattern als solches, sondern um das generelle Verbot von Dingen, die man selbst für nicht sinnvoll erachtet. Das schränkt Entwickler unnötig ein und hat, in den allermeisten Fällen, einen eher negativen Effekt. Wir können uns vom Singleton wegbewegen (es gibt durchaus nicht-exotische Anwendungsfälle für dieses Pattern, das will ich hier aber gar nicht weiter ausführen) und zu den statischen Methoden kommen. Ich halte in OOP von statischen Methoden überhaupt nichts, würde aber nie auf die Idee kommen, eine Richtlinie zu verfassen, die den Einsatz statischer Methoden generell verbietet. Jeder Entwickler sollte genügend Freiraum haben, Dinge so umsetzen, wie er es für sinnvoll erachtet. Dazu gehört aber auch, dass sich Entwickler der Vor- und Nachteile ihrer jeweils genutzten Lösung bewusst sind. Ich habe Restriktionen in Richtlinen, die für mich keinen Sinn ergaben, immer hinterfragt. Kam dann für mich keine zufriedenstellende Antwort, habe ich den Arbeitgeber gewechselt. Heute, viele Jahre später, entwerfe ich solche Richtlinien selbst und vermeide Restriktionen in diesen ganz bewusst, da für mich andere Dinge deutlich wichtiger sind, als den Entwicklern aufzuoktroyieren, was sie zu tun und zu lassen haben. Allerdings sortiere ich in den Bewerbungsgesprächen relativ strikt ungeeignete Kandidaten aus, bei den passenden Bewerbern bin ich mir dann recht sicher, dass sie keine Richtlinien brauchen, die sie unnötig einschränken.
Wie heißt eigentlich das lol.poop().unwrap().nepp("ja").unwrap().wasischnischwasdashiertut('viel spaß damit!'); Pattern? Die schlimmste newskool-Seuche von allen.
Functional Programming nennt sich das
Piping oder Chaining
@@boredbytrashnö