Objekt nur einmalig zulassen
Guten Abend zusammen,
ich habe derzeit mit einem vermutlich hausgemachten (nur in meinem Kopf?) vorhandenem Problem zu kämpfen. Ich möchte ich Objekt einer selbst geschriebenen Klasse in einem Timer erstellen. Um kurz zu veranschaulichen was ich damit meine:
void timer_Tick(object sender, EventArgs e)
{
Challenge test1 = new Challenge();
test1.run();
}
Problem dabei ist, dass Challenge nur exakt einmal erstellt werden darf (ungeachtet welche Logik dahinter steht und wie meine Klasse aussieht). Leider will es mir nicht gelingen, eine passende If-Kontrollstrutkur zu formulieren. Mein erster Gedanke war, dass ich ein Objekt vom Typ Object vordefiniere und später dann einfach caste. Ich würde also einfach prüfen, ob test1 vom Typ System.Object ist und dann entsprechend den cast vornehmen. Dabei treten die beiden Probleme auf, dass das Visual Studio es nicht zulässt, die Run-Methode aufzurufen, sofern sich die Initialisierung in einer Kontrollstruktur befindet. Hinzu kommt, dass zum Zeitpunkt vor dem Programmstart noch keine Methode Run existiert. Letzteres Problem hätte ich mit einer leeren Methode lösen können, kam mir also aber sehr unsauber vor.
Meine Bitte / Frage also an euch, was habe ich hier für Möglichkeiten?
Danke.
Mit freundlichem Gruß
Vitafit
Hallo vitafit,
schau dir mal das Singleton-Muster an. Das hilft dir immer nur eine Instanz vom Objekt zu erstellen.
Gruss
Coffeebean
Microsoft MVP // Me // Blog // GitHub // @Egghead // All my talks // Speakerdeck
Hallo vitafit,
kannst du das Challenge-Objekt nicht im z.B. Konstruktor der Klasse (in der die timer_Tick-Methode ist) erstellen und im Tick einfach die Run-Methode aufrufen?
mfG Gü
Stellt fachliche Fragen bitte im Forum, damit von den Antworten alle profitieren. Daher beantworte ich solche Fragen nicht per PM.
"Alle sagten, das geht nicht! Dann kam einer, der wusste das nicht - und hat's gemacht!"
Vielen Dank euch beiden, hat mir wirklich geholfen. Werde wohl vorübergehend zu Coffeebgfoidl's Methodik greifen. Auf lange Sicht führt aber eindeutig kein Weg an Singleton vorbei. Danke!
Auf lange Sicht führt aber eindeutig kein Weg an Singleton vorbei.
Das sehe ich anders.
Im Normalfall ist es besser, ein Objekt nur einmal zu erstellen, wenn es nur einmal gebraucht wird und es dann an alle weiterzugeben, die es brauchen.
Ein Singleton führt hingegen häufig zu komplexen Abhängigkeiten und wir daher auch zunehmend als Antipattern gesehen, welches globale Variablen auch in Sprachen ermöglicht, die das eigentlich nicht vorsehen.
Hallo vitafit,
Werde wohl vorübergehend zu Coffeebgfoidl's Methodik greifen.
Welche nun?
Auf lange Sicht führt aber eindeutig kein Weg an Singleton vorbei.
Ein Singleton ist selten die beste Lösung. Kannst du über Forensuche nach Singleton nachlesen.
mfG Gü
Stellt fachliche Fragen bitte im Forum, damit von den Antworten alle profitieren. Daher beantworte ich solche Fragen nicht per PM.
"Alle sagten, das geht nicht! Dann kam einer, der wusste das nicht - und hat's gemacht!"
Im Normalfall ist es besser, ein Objekt nur einmal zu erstellen, wenn es nur einmal gebraucht wird und es dann an alle weiterzugeben, die es brauchen.
Genau das kann man doch auch mit dem Singleton? Die Abhängigkeiten von Klassen sind ja überall die selben. Was spricht dagegen, wenn jeder sich das Objekt selber holt?
Für Konfigurationen oder sonstige globale Infos möchte ich mir nicht immer irgendwelche Referenzen hin und her übergeben. Da ists doch grad schön wenn jeder sich dieses Objekt ei Bedarf selbst holen kann.
Stellt fachliche Fragen bitte im Forum, damit von den Antworten alle profitieren. Daher beantworte ich solche Fragen nicht per PM.
"Alle sagten, das geht nicht! Dann kam einer, der wusste das nicht - und hat's gemacht!"
Genauso "schlimm" wie singleton ist eine static class.
Grüße Bernd
Workshop : Datenbanken mit ADO.NET
Xamarin Mobile App : Finderwille Einsatz App
Unternehmenssoftware : Quasar-3
Evtl. wäre auch das Monostate-Pattern eine Alternative, welches Robert C. Martin in eines seiner Bücher beschreibt, s.a. PDF: Singleton and Monostate aus The Principles, Patterns, and Practices of Agile Software Development
Hallo chilic,
Was spricht dagegen, wenn jeder sich das Objekt selber holt?
in erster Linie spricht mal dagegen, dass das Kriterium für Singleton nicht der einfache Zugriff ist, sondern dass es von der Klasse prinzipiell nur ein Objekt geben kann und sich das nie ändern wird. Deshalb heiß es _Single_ton und nicht _GlobalAccess_ton oder _EasyAccess_ton. 😃
Für Konfigurationen oder sonstige globale Infos möchte ich mir nicht immer irgendwelche Referenzen hin und her übergeben.
Konfiguration, ok, gekauft. Aber "sonstige globale Infos" ist mir viel zu schwamig. Es ist ja allgemein anerkannt, dass globale Objekte und Zugriffe nach Möglichkeit vermiedenen werden sollten, weil sie schnell zuviele unnötige und schwer zu durchschauende Abhängigkeiten schaffen. Deshalb sollte man sehr, sehr zurückhaltend sein, auf welche Objekte man einen globalen Zugriff zur Verfügung stellt.
Die "Easyness", wenn man Objekte, die man an verschiedenen Stellen braucht, einfach global verfügbar macht, ist oft genau das Problem, weil das dazu verleitet, hier und dort auch noch darauf zuzugreifen, weils so schön einfach ist. Beim Erstellen mag es einfach sein, beim Test und erst recht bei der Wartung präsentiert sich dann die Rechnung in Form von schwer zu findenden Fehlern oder überraschenden und störenden Abhängigkeiten.
Die Referenzen gezielt an die Stellen zu übergeben, wo ein Zugriff wirklich nötig/unvermeidbar ist, führt dagegen normalerweise zur der nötigen Disziplin.
Es gibt sehr wenige Ausnahmen, die diese Regel bestätigen. Eine wurde hier genannt: Konfigurationsdaten. Eine in dem schon verlinkten Thread Nur eine LogWriter-Instanz in allen anderen Klassen verwenden.
herbivore