@Sylence: Danke für die Klarstellung - dann verwende ich jetzt keine Destruktoren mehr, sondern die erwähnte Unregister-Methode.
@Sacaldur: Meiner Meinung lohnt es sich definitiv bei 20 verschiedenen Generic-Parametern auch 20 Listen anzulegen um ein ständiges Filtern zu umgehen, denn in der Matrix wird immer nur ein Generic-Typ benötigt. Nun stellt sich mir die Frage, ob ich in einer Modelklasse 20 Collections anlegen soll, die alle das exakt gleiche Verhalten besitzen. Außerdem stelle ich mir damit doch selbst ein Bein, weil ich dann 20 verschiedene Variablennamen habe, die alle beim Hinzfügen, Lesen und Entfernen aus diesen Listen unterschieden werden müssen. Wenn ich dann am Ende noch einen 21 Werttyp einführe, dann darf ich an x-Stellen einen weiteren Variablennamen einprogrammieren - mit entsprechender Unterscheidungslogik.
Ich mache mal ein Beispiel:
|
C#-Quelltext
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
|
// Werttypen (Klassen): RGBValue, PositionValue, IntensityValue, etc.
// Die Projektklasse verwaltet Auflistungen und Eigenschaften, die eine Lichtshow global betreffen
public static class Project
{
public static ObservableHashSet<InputPin<RGBValue>> AllRGBInputPins { get; private set; }
public static ObservableHashSet<InputPin<PositionValue>> AllPositionInputPins { get; private set; }
public static ObservableHashSet<InputPin<IntensityValue>> AllIntensityInputPins { get; private set; }
public static ObservableHashSet<OutputPin<RGBValue>> AllRGBOutputPins { get; private set; }
public static ObservableHashSet<OutputPin<PositionValue>> AllPositionOutputPins { get; private set; }
public static ObservableHashSet<OutputPin<IntensityValue>> AllIntensityOutputPins { get; private set; }
}
// Generisches ViewModel, dessen GenericParameter je nach gewähltem Typ gesetzt wird
public class MatrixViewModel<T> : IMatrixViewModel
{
public void UpdateMatrixElements()
{
ObservableHashSet<InputPin<T>> AllInputPins;
ObservableHashSet<OutputPin<T>> AllOutputPins;
if(T is RGBValue)
{
AllInputPins = AllRGBInputPins; // Hier darf ich dann auch noch eine nette Konvertierung machen
AllOutputPins = AllRGBOutputPins; // s.o.
}
else if(T is PositionValue)
{
AllInputPins = AllPositionInputPins; // s.o.
AllOutputPins = AllPositionOutputPins; // s.o.
}
else if(T is IntensityValue)
{
AllInputPins = AllIntensityInputPins; // s.o.
AllOutputPins = AllIntensityOutputPins; // s.o.
}
else
{
throw new ValueTypeNotSupportedException();
}
// AllInputPins und AllOutputPins weiterverarbeiten (Matrix-Header erzeugen und Matrix-Elemente
}
}
|
Wenn ich jetzt einen weiteren Typ einführen möchte, dann darf ich jedes mal die If-Else erweitern.
Wenn ich meine Instanceklassen verwende, dann sähe das so aus:
|
C#-Quelltext
|
1
2
3
4
5
6
7
|
public void UpdateMatrixElements()
{
ObservableHashSet<InputPin<T>> AllInputPins = InputPins<T>.Instances; // Keine Konvertierung nötig - sogar das "Observable" bleibt erhalten!
ObservableHashSet<OutputPin<T>> AllOutputPins = OutputPins<T>.Instances;
// AllInputPins und AllOutputPins weiterverarbeiten (Matrix-Header erzeugen und Matrix-Elemente
}
|
Ehrlich gesagt bezweifle ich stark, dass ich verstehe was du mit "Du könntest diese ebenso in einer Model-Klasse hinterlegen." meinst, denn ich bin der Meinung, dass dir bewusst bist, dass bei dem oberen Beispiel die Vorzüge der Generics zu einem Großteil verlohren gehen würden.