Hallo, ich arbeite an einem Programm, wo ich viele Fenster habe, die als Schaltflächen dienen, die man überall auf dem Bildschirm verteilen kann. Wenn davon eine betätigt wird, muss ich wissen, welche das war.
Jetzt ist meine Frage: Ist es in Ordnung, in dem Fall ein static Feld zu deklarieren? Oder wie sollte ich vorgehen? Das Fenster mit der Schaltfläche sollte auch selber wissen, dass es zuletzt betätigt wurde, weil es sich entsprechend einfärbt.
Ich weiß, es ist etwas unspezifisch. Aber ich lese überall, dass man static felder vermeiden sollte, aber hier erscheint mir das die beste Lösung.
Oder sollte ich besser ein Event erzeugen, das dem Erzeuger dieser Fenster mitteilt, wenn eins betätigt wurde, woraufhin er den anderen Fenstern mitteilt, dass sie nicht mehr das zuletzt betätigte sind?
Grüße
Tobias
Sprichst Du von Feldern oder Eigenschaften?
Aber ja: static gilt es zu vermeiden.
Daher:
die beste Lösung.
No, sicher nicht 😉
Was Du willst ist prinzipiell ein State, der allen Fenstern bekannt ist.
Das kann man problemlos via Dependency Injection lösen, oder aber auch mit Reactive Extensions.
Um genauer zu helfen musst Du konkreter werden.
- performance is a feature -
Microsoft MVP - @Website - @AzureStuttgart - github.com/BenjaminAbt - Sustainable Code
Was Du willst ist prinzipiell ein State, der allen Fenstern bekannt ist.
Es geht mir ziemlich genau darum.
Die Fenster müssen wissen, welches zuletzt aktiv war. Ich denke, es sollte Eigenschaft sein.
Naja, dann machst Dir nen WindowState - kann man prinzipiell einfach selbst machen.
public class WindowStateManager // Such Dir einen besseren Namen aus
{
public Window CurrentWindow {get;set;}
public Window LastWindow {get;set;}
}
Dann kannst von jedem Window auf die Instanz zugreifen und CurrentWindow
setzen.
Kannst das auch so noch machen, dass beim Setzen von CurrentWindow
automatisch LastWindow
gesetzt wird.
Sorgst dafür, dass die Anwendung nur eine einzige Instanz dieser Klasse hat (Singleton).
Verwendest Du kein Dependency Injection, was ich nicht hoffe, wirst Du leider kaum um eine statische Instanz der Klasse drumrum kommen (C# Lazy Singleton Pattern zB.).
Statische Instanzen vermeidet man vor allem deshalb, weil sie nahezu nicht oder nur mit sehr hohem Aufwand zu testen sind.
[Artikel] Unit-Tests: Einführung in das Unit-Testing mit VisualStudio
Und Testbarkeit ist das A und O.
- performance is a feature -
Microsoft MVP - @Website - @AzureStuttgart - github.com/BenjaminAbt - Sustainable Code
Wieso ist die statische Klasse jetzt besser, als ein statisches Feld bzw. Eigenschaft?
Hab ich nicht gesagt; ist beides nicht toll.
Besseren Weg hab ich ja erklärt: State via Dependency Injection.
Und das geht halt nur über eine Klasse und nicht über eine Eigenschaft.
Daher auch das Beispiel.
- performance is a feature -
Microsoft MVP - @Website - @AzureStuttgart - github.com/BenjaminAbt - Sustainable Code
Zunächst mal Danke für die Information.
Jetzt habe ich mal nach Dependency Injection gesucht und glaube, allgemein verstanden zu haben, wie es gedacht ist.
Das heißt jetzt, dass ich beim Erstellen eines der besagten Fenster diese WindowState Klasse im Konstruktor übergebe. Dann kann ich darüber das aktuelle Fenster ermitteln.
Meine Software zeigt zunächst das Fenster Mainwindow an, von wo dann die Schaltflächen (Instanzen von InteractorWin) erstellt werden.
Dann würde ich im Mainwindow diese Klasse ein Mal deklarieren und bei jedem Erstellen einer Schaltfläche mit übergeben.
Richtig? 😉
Du registrierst alle Abhängigkeiten.
Willst Du dann ein Window öffnen, verwendest Du serviceProvider.GetRequiredService<MeinWindow>() (je nachdem welchen ServiceProvider Du verwendest).
Die Abhängigkeiten werden dann automatisch aufgelöst.
Du kannst auch erst mal alles so belassen, und nur Deinen WindowState registrieren.
In Deinen Fenster verwendest dann im Konstruktor GetRequiredService<WindowState>() - nennt man dann Service Locator Pattern.
Der SLP ist nicht unbedingt zu empfehlen, bringt Dich aber schon mal ein Stück weiter Richtung Dependency Injection.
- performance is a feature -
Microsoft MVP - @Website - @AzureStuttgart - github.com/BenjaminAbt - Sustainable Code
Oder sollte ich besser ein Event erzeugen, das dem Erzeuger dieser Fenster mitteilt, wenn eins betätigt wurde, woraufhin er den anderen Fenstern mitteilt, dass sie nicht mehr das zuletzt betätigte sind?
Das wäre die bessere Lösung. Das Fenster muß nichts über die anderen Fenster wissen. Diese Logik sollte im "Erzeuger" (WindowManager o.ä.) implementiert sein. Dann braucht man auch keine statischen Eigenschaften oder DI.
Weeks of programming can save you hours of planning