Hallo!
Ich hoffe, dass ich das Problem vernünftig beschreiben kann.
Es gibt N Formulare.
Jedes Formular soll einen gemeinsamen Code benutzen, der sich ändern kann.
Wenn ich also den Code in jedes Formular schreibe, muss ich N Formulare ändern.
Das ist bei einer großen Anzahl an Formularen eine irre Arbeit.
Bei C++ würde ich so etwas durch einen include lösen.
Das gibt es bei C# aber nicht.
Es geht um mehrere Handler.
Einer davon ist der ON_PAINT Handler.
Dort werden Sachen gemacht, die zu 70% identisch sind, aber 30% sind unterschiedlich.
Ich könnte eine Klasse OP_Handler machen und die dann immer so aufrufen:
public void ON_PAINT(PaintEventArgs e)
{
opHandler.meineFunktion(e);
}
Den OP_Handler vorher mit new OP_Handler(this) ...
Nur würde er dann nur die Standard Funktionen kennen, nicht meine, da jeder Form ja anders heißt.
Nun ist das Problem, dass im OP Handler e.garphics..etc nutzbar sind, aber solche Sachen wie
Zugriff auf eine eigene Funktion in der jeweiligen Form geht nicht.
Wie löst man solche Probleme am elegantesten?
Ich hoffe, ich habe mich richtig ausgedrückt, so dass man das Problem versteht.
Olaf
Hallo!
Ja, zu dem Ergebnis bin ich dann auch gekommen.
Das wird dann so aussehen:
Layout <- CommonG <- GtypeX <- startclass1
Layout <- CommonG <- GtypeY <- startclass2
Layout <- CommonE <- EtypeX <- startclass3
etc
Ich muss es tatsächlich in ein N-Schichten Modell aufteilen.
Aber damit wird es dann gehen.
Da trauere ich dem include und den virtuellen Klassen hinterher.
Ich frage mich, was gegen diese beiden Sachen sprach, als die C# designed haben.
Olaf
Auch in C++ ist es ein schlechtes Design, dies mittels 'include' (oder sogar Makros) zu lösen!
Abstrakte Klassen und/oder Interfaces sind hier der richtige Weg (d.h. das Strategy-Pattern).