Super Video! Genau so sollte es sein, keine Static-Klassen. 🙂 Doch ich verwende das Singelton-Pattern ausschließlich über einen IoC-Container, denn dort habe ich alle Registrierungen an einem Ort. Und es ist ganz easy, ob eine Klasse im Nachhinein nur eine Instanz haben soll oder nicht, das kann ich in der Registrierungsfunktion bequem einstellen (falls sich das Design noch ändern sollte).
@@CodingmitJannick Gerne. Perfekt! Das sind wichtige Themen, wie z.B. auch Unit-Tests. Wird leider bei Desktop-Anwendungen noch nicht überall eingesetzt, bzw. ist noch kein Standard (ist zumindest meine Erfahrung). Bei Web- und Mobil-Anwendungen ist das zum Glück schon Standard.
@@CodingmitJannick Ja, genau. Beides. Und ich kriege es immer wieder mit, dass diese Konzepte nicht jedem bekannt sind und einige verstehen den Sinn dahinter nicht, auch weil es zuerst einmal kurzfristig mehr Aufwand bedeutet (angefangen bei DI und auch Interfaces als Design- und Architekturwerkzeug, sowie UnitTests). In der Web-/Mobile-Welt hat sich das schon etabliert, die gängigen Frameworks bringen das schon von Haus aus mit. Deswegen finde ich auch solche Videos wichtig, die dann Themen aus den Bereichen BestPractises, DesignPatterns, Clean Code, Design- und Architekturkonzepte erläutern und erklären, wie bei dir. Vielleicht kommen noch mehr davon. ;-) - ich fände es super 🙂 Du strukturierst die Themen in deinen Videos sehr gut und erklärst es verständlich mit tollen Beispielen. 🙂
Also, das Pattern an sich ist ziemlich verständlich erklärt. Aber, was nicht erklärt wurde: Warum ist es nah zu immer ein Anti-Pattern? (sogar das im Video gezeigte Beispiel) Was sind die Nachteile? Was sind die Alternativen? Warum sollte man meistens sein Design überdenken, wenn man einen Singleton verwenden "muss"? Gerade wenn Anfänger Singletons verwenden, schadetet es mehr, als es einem bringt. Edit: Ich rede von den SIngletons in diesem Video. Nicht von Singletons in einem IoC Container.
Guter Blickwinkel, ich denke, dass es für fast jedes Pattern Sinn macht mal darüber zu sprechen wo die Pitfalls sind und ob sich dahinter ein Anti-Pattern verbirgt. Merke ich mir 🙂 Bei diesem Pattern muss ich sagen, dass es gerade bei kleineren Konsolen- oder Desktopanwendungen doch schon nützlich sein kann. Bei größeren Webanwendungen würde man ja einen IoC container verwenden, da wüsste ich also nicht wieso jemand überhaupt das alleinstehende Singleton Pattern verwenden würde. Danke 👍
Bei kleinen Projekten ist absolut nichts dagegen einzuwenden. Wenn die Codebase aber größer wird und man auf einmal merkt, dass man doch nicht eine Instanz von etwas braucht sondern doch mehrere, darf man den ganzen Kram umbauen und hat sich mit nem Singleton.getInstance() etwas in die Ecke manövriert. Abhilfe schafft da üblicherweise IoC/DependencyInjection oder irgendeine "verwaltende" Stelle, die Instanzen erstellt und verteilt. Dazu vergessen weniger erfahrene Entwickler:innen gerne mal das locking, was zu richtig nervigen und seltenen bugs führen kann.
@@hisf1shness das nichts dagegen spricht würde ich nicht sagen 🤔 aber es ist relativ egal, da man ihn Verhältnismäßig schnell umbauen kann, wenn er Probleme macht. 🤔 Klar, bei Helferlein, die man sich in paar Minuten hin Pfuscht, weil man es kann (.. also weil man zu faul ist etwas ständig manuell zu machen.. 😂) dann ist sowieso alles an Programmierregeln und best practice egal 😂 solche "Projekte" hat jeder zu genüge 😂
Sehr gute Frage! Wie gesagt, bei Pattern geht es um Clean Code und OOP Prinzipien. Hier gibt es eine komplette Debatte zu deiner Frage: stackoverflow.com/questions/2969599/why-use-singleton-instead-of-static-class Ich selber verwende lieber das Pattern weil es sich nahtloser einfügt und nicht im Global Namespace ist. VG :-)
Hatte letztens bei einem Coding Stream von Yunus von DA mit einem geschattet, der sich gewundert hat, dass man Design Patterns nachcoden kann. Da frag ich mich eher, warum nicht?
Darum nutzt man einfach Kotlin, wo für ein Objekt mit einer einzigen Instanz logischerweise erst gar keine Klasse erstellt wird (keyword object statt class)
In diesem Video das #1 Pattern, bei uns in der Firma der #1 Grund wieso der Merge-Request abgelehnt wird. Und das im Video nicht auf die Gefahren bei diesem Pattern hingewiesen wird, ist fast schon fahrlässig m.M.n.
Hi, danke für die Anmerkung, das Singleton Pattern hat einige Pitfalls. Ich erwähne aber auch nicht, dass man diese Pattern immer verwenden sollte, sondern nur, dass das Pattern das wohl bekannteste und immer noch häufig (sogar sehr häufig) verwendet wird. Unabhängig davon plane ich bereits Videos zum Thema Anti-Patterns. Darunter dann auch das Singleton Pattern. VG
☑ Die C# Checkliste findest du hier:
codingmitjannick.de
Bei großen Projekten ist das Singleton ein klassisches Anti Pattern, sollte man bedenken. Gründe & Beispiele gibts zu Hauf im Internet zu finden
Ja, ich habe mir bereits überlegt dazu ein Video zu machen. Also Anti-Patterns am Beispiel Singleton 🙂
Wollte ich auch sagen. Bei größeren Projekten sind IoC Frameworks besser.....
Danke für das Video ohne Foo und Bar zu benutzten. ;)
Schönes Video, sehr gut erklärt!!!
Vielen Dank!
Super Video! Genau so sollte es sein, keine Static-Klassen. 🙂
Doch ich verwende das Singelton-Pattern ausschließlich über einen IoC-Container, denn dort habe ich alle Registrierungen an einem Ort. Und es ist ganz easy, ob eine Klasse im Nachhinein nur eine Instanz haben soll oder nicht, das kann ich in der Registrierungsfunktion bequem einstellen (falls sich das Design noch ändern sollte).
Super Input! Ich werde zum Thema IoC-Container bzw. DI generell mal ein Video erstellen.
VG
@@CodingmitJannick Gerne. Perfekt! Das sind wichtige Themen, wie z.B. auch Unit-Tests. Wird leider bei Desktop-Anwendungen noch nicht überall eingesetzt, bzw. ist noch kein Standard (ist zumindest meine Erfahrung).
Bei Web- und Mobil-Anwendungen ist das zum Glück schon Standard.
@@ProgrammierungLeichtGemacht Du meinst vor allem WPF/Forms, oder?
@@CodingmitJannick Ja, genau. Beides.
Und ich kriege es immer wieder mit, dass diese Konzepte nicht jedem bekannt sind und einige verstehen den Sinn dahinter nicht, auch weil es zuerst einmal kurzfristig mehr Aufwand bedeutet (angefangen bei DI und auch Interfaces als Design- und Architekturwerkzeug, sowie UnitTests). In der Web-/Mobile-Welt hat sich das schon etabliert, die gängigen Frameworks bringen das schon von Haus aus mit.
Deswegen finde ich auch solche Videos wichtig, die dann Themen aus den Bereichen BestPractises, DesignPatterns, Clean Code, Design- und Architekturkonzepte erläutern und erklären, wie bei dir. Vielleicht kommen noch mehr davon. ;-) - ich fände es super 🙂
Du strukturierst die Themen in deinen Videos sehr gut und erklärst es verständlich mit tollen Beispielen. 🙂
Könntest du mal ne Blazor Serie machen wäre echt cool
Klaro, habe auch vor dazu einen ganzen Kurs zu machen 🙂Inkl. TH-cam Serie
@@CodingmitJannick der Kurs is jetzt schon gekauft, bitte aber in deutsch, in deutsch gibt es keine keine Tutorials zu Blazer.
Geiles Video! Ergibt das eigentlich auch beim mvvm Pattern Sinn?
Auf jeden Fall 🙂Wo auch immer Services/Manager bereitgestellt werden müssen, ergibt das Singleton Pattern Sinn.
VG
@@CodingmitJannick Nun, ich meine für Viewmodels, die dauerhaft verwendet werden.
Also, das Pattern an sich ist ziemlich verständlich erklärt.
Aber, was nicht erklärt wurde:
Warum ist es nah zu immer ein Anti-Pattern? (sogar das im Video gezeigte Beispiel)
Was sind die Nachteile?
Was sind die Alternativen?
Warum sollte man meistens sein Design überdenken, wenn man einen Singleton verwenden "muss"?
Gerade wenn Anfänger Singletons verwenden, schadetet es mehr, als es einem bringt.
Edit: Ich rede von den SIngletons in diesem Video. Nicht von Singletons in einem IoC Container.
Guter Blickwinkel, ich denke, dass es für fast jedes Pattern Sinn macht mal darüber zu sprechen wo die Pitfalls sind und ob sich dahinter ein Anti-Pattern verbirgt. Merke ich mir 🙂
Bei diesem Pattern muss ich sagen, dass es gerade bei kleineren Konsolen- oder Desktopanwendungen doch schon nützlich sein kann.
Bei größeren Webanwendungen würde man ja einen IoC container verwenden, da wüsste ich also nicht wieso jemand überhaupt das alleinstehende Singleton Pattern verwenden würde.
Danke 👍
Bei kleinen Projekten ist absolut nichts dagegen einzuwenden. Wenn die Codebase aber größer wird und man auf einmal merkt, dass man doch nicht eine Instanz von etwas braucht sondern doch mehrere, darf man den ganzen Kram umbauen und hat sich mit nem Singleton.getInstance() etwas in die Ecke manövriert. Abhilfe schafft da üblicherweise IoC/DependencyInjection oder irgendeine "verwaltende" Stelle, die Instanzen erstellt und verteilt. Dazu vergessen weniger erfahrene Entwickler:innen gerne mal das locking, was zu richtig nervigen und seltenen bugs führen kann.
@@hisf1shness das nichts dagegen spricht würde ich nicht sagen 🤔 aber es ist relativ egal, da man ihn Verhältnismäßig schnell umbauen kann, wenn er Probleme macht. 🤔
Klar, bei Helferlein, die man sich in paar Minuten hin Pfuscht, weil man es kann (.. also weil man zu faul ist etwas ständig manuell zu machen.. 😂) dann ist sowieso alles an Programmierregeln und best practice egal 😂 solche "Projekte" hat jeder zu genüge 😂
Ich frage mich, warum die Klasse selbst nicht static ist?
Sehr gute Frage! Wie gesagt, bei Pattern geht es um Clean Code und OOP Prinzipien. Hier gibt es eine komplette Debatte zu deiner Frage:
stackoverflow.com/questions/2969599/why-use-singleton-instead-of-static-class
Ich selber verwende lieber das Pattern weil es sich nahtloser einfügt und nicht im Global Namespace ist.
VG :-)
@@CodingmitJannick Danke für den Link 🙂 Und gutes Video übrigens.
Hatte letztens bei einem Coding Stream von Yunus von DA mit einem geschattet, der sich gewundert hat, dass man Design Patterns nachcoden kann. Da frag ich mich eher, warum nicht?
Mit Java oder C# wird man zum CEO of Boilerplate.
Darum nutzt man einfach Kotlin, wo für ein Objekt mit einer einzigen Instanz logischerweise erst gar keine Klasse erstellt wird (keyword object statt class)
Java mit springboot und lombok ist ganz anders als java vor 15 Jahren...
In diesem Video das #1 Pattern, bei uns in der Firma der #1 Grund wieso der Merge-Request abgelehnt wird. Und das im Video nicht auf die Gefahren bei diesem Pattern hingewiesen wird, ist fast schon fahrlässig m.M.n.
Hi, danke für die Anmerkung, das Singleton Pattern hat einige Pitfalls. Ich erwähne aber auch nicht, dass man diese Pattern immer verwenden sollte, sondern nur, dass das Pattern das wohl bekannteste und immer noch häufig (sogar sehr häufig) verwendet wird.
Unabhängig davon plane ich bereits Videos zum Thema Anti-Patterns. Darunter dann auch das Singleton Pattern.
VG