Frage zum überschreiben von Methoden

So...
Wieder einmal eine Frage, welche sich durch den Umstieg von VFP auf C# ergibt.

Diesmal geht es um das Überschreiben von Methoden.

Ich habe z.B. eine Buttonklasse "BasisButton".
In dieser Klasse gibt es eine Methode lock().
Diese Methode wird aufgerufen wenn sich deiser Button auf einer Form befindet und dann z.B. beim Ändern durch eine schleife aufgerufen wird,,welche alle Bottons durch geht, die die lock()-Methode haben.

Jetzt soll EIN bestimmter Button aber nicht die Standard-Programmierung aus dieser Klasse machen, sondern etwas anderes, z.b. genau das entgegengesetzte.

Der Objektorientierte ansatz wäre jetzt vermutlich folgender:

class SpezialButton 
{
    public override void lock(bool sperren)
    {
        base.lock(!sperren);
    }
}

Ich muss mit also einen neuen knopf Ableiten, in welchen ich die Methode so überschreibe, wie ich sie brauche.
Wenn ich das jetzt für 5 Bottons, bei 3 verschiedenen Methoden habe, bedeutet das, das ich locker mal bis zu 9 abgeleitete Buttons haben kann, weil alle was anderes machen.

In VFP war dies anders.
Da konnte man einfach in den Eigenschaften auf den Reiter "Events/Methoden" gehen und die Spezielle Methode dieses speziellen Buttons umschreiben.

So einen Reiter "Events" gibt es im Eigenschaften Fenster zwar immer noch, aber dort sind keine Methoden gelistet, nur Events.

Bedeutet dies jetzt, das mein BasisButton zwingend einen Event braucht, damit ich diesen dort umschreiben kann, wo ich das umgeschriebene Event brauche?

o einen Reiter "Events" gibt es im Eigenschaften Fenster zwar immer noch, aber dort sind keine Methoden gelistet, nur Events.

wenig überraschend.

Bedeutet dies jetzt, das mein BasisButton zwingend einen Event braucht, damit ich diesen dort umschreiben kann, wo ich das umgeschriebene Event brauche?

events lassen sich nciht überschreiben....
generell solltest du dich von der art und weise der programmierung, wie du sie früher gemacht hast.... loslösen.

zu deinem problem:
eine möglichkeit ist es dekoratoren zu schreiben und dann einfach auf die buttons anzuwenden. so eine art wrapper z.b.

schön wäre zudem ncoh zu wissen, was genau du vor hast. ich habe das gefühl das du einen falschen weg beschreitest.

Du könntest einfach hergehen und in deiner Basisklasse einen Enum ButtonTyp anlegen und in den Methoden entsprechend dem Typ reagieren.

nichts für ungut aber DAS würde ich in keinem fall machen

Was ich machen möchte ist.... ich möchte das, was der Button in der abgeleiteten Klasse macht überschreiben.

Das machen wir hier jeden Tag und gehört zur ganz normalen vorgehensweise dazu.
Manchmal hat man eben den Fall, dass man nicht das möchte, was der Button normalerweise macht, sondern etwas anderes.

Dann müsste ich erst wie oben beschreiben diesen Button noch mal ableiten und in diesem Abgeleiteten Button die Methode überschreiben, die es betrifft.

Sprich... ich hab jetzt einen Abgeleiteten Button BasisButton:

class BasisButton:Button {}

In dem ist irgednwo eine Methode "lock()" definiert, die einen bool entgegen nimmt, und dann entscheidet ob enabled=true oder false, je nach übergeben bool.
Die eigene lock() methode deshalb, weil es diese auch in einer Textbox gibt.
Dort möchte man aber z.b. kein Enabled=true/false haben, sondern ein Readonly, weil sich die textbox anders verhält.

Möchte ich jetzt also für einen Bestimmten Button nicht, das dieser die standard-Programmierung ausführt, weil dieser z.b. IMMER enabled sein soll, muss ich diesen Button noch mal ableiten:

class SpezialButton:BasisButton
{
    public override void lock(bool sperren)
    {
        // Auskommentiert, weil soll immer Enabled sein
        //base.lock(sperren);
    }
}

Und diesen Button müsste ich dann auf meiner Form benutzen.

Ich würde mich wirklich sehr gern von allem loslösen - aber dazu brauch ich ein wenig geistige Hilfe, wie man es "normal" machen würde 😃

Wo sind meine lieben Ex-VFP´ler hin? 😉

ich möchte das, was der Button in der abgeleiteten Klasse macht überschreiben.

ja, das sei bereits erwähnt.

Manchmal hat man eben den Fall, dass man nicht das möchte, was der Button normalerweise macht, sondern etwas anderes.

ja, das ist an sich ncihts verwerfliches.

Dann müsste ich erst wie oben beschreiben diesen Button noch mal ableiten und in diesem Abgeleiteten Button die Methode überschreiben, die es betrifft.

das ist die standard vorgehensweise.

wenn man allerdings exponenzielles wachstum bei der anzahl der abgeleiteten klassen verzeichnet... dann sollte man sich nochmals gedanken über die architektur machen.

In dem ist irgednwo eine Methode "lock()" definiert, die einen bool entgegen nimmt, und dann entscheidet ob enabled=true oder false, je nach übergeben bool.
Die eigene lock() methode deshalb, weil es diese auch in einer Textbox gibt.
Dort möchte man aber z.b. kein Enabled=true/false haben, sondern ein Readonly, weil sich die textbox anders verhält.

und genau das hier ist der springende punkt. das was du machen willst erreicht man besser über einen decorator. den appliest du einfach an alle buttons und über den rufst du dann auch die Lock-methode auf. dann hast du 3 dekoratoren. einer der readonly macht, einer der enabled setzt und einen der ncihts macht.

Öhm...
Dann muss ich für jede Spezialprogrammierung, welche von der Standard-Programmierung abweicht so ein eigenes Decoration-Ding basteln?

...oder mir grundlegend Gedanken über meine Architektur machen?

von wievielen spezialprogrammierungen reden wir hier?

und prinzipiell..... ja.

...oder mir grundlegend Gedanken über meine Architektur machen?

vermutlich schon.... mir ist zumindest in meiner laufbahn noch nie die idee gekommen ein und das selbe control durch ableitungen in seinem verhalten zu ändern, wenn ich das gleiche einfach durch das äußere setzen einer eigenschaft erreichen kann......

Hallo,

möglich wäre es doch auch, einen Event zu feuern, der ähnlich wie die KeyPress-Events eine Handled-Eigenschaft hat.

Beispiel (ist jetzt ungetestet aber ihr wisst schon worauf ich hinaus will):

MyFirstClass {
 public void Lock() {
  MyEventArgs args = new MyEventArgs();
  OnLock(this, args);
  if(!args.Handled){
   // Do Something
  }
 }
}

MyEventArgs {
 public bool Handled { get; set; }
}

MySecondClass : MyFirstClass {
 MySecondClass() : base() {
  base.Lock += new EventHandler<MyEventArgs(...);
 }

 private void BaseLock(object sender, MyEventArgs e){
  e.Handled = true;
  // Do Something
 }
}

Du könntest einfach hergehen und in deiner Basisklasse einen Enum ButtonTyp anlegen und in den Methoden entsprechend dem Typ reagieren.

nichts für ungut aber DAS würde ich in keinem fall machen

Hallo JAck30lena,
warum sollte man das so nicht machen? (reine Neugier)

weil das schnell ausartet und der code vom button unwartbar wird. dann hat man einen monolithbutton der alles kann, wenn die korrekten flags gesetzt sind aber wehe wenn ein flag nicht korrekt ist.....

solange das nur bei 2-3 states bleibt und man sicher sein kann ,das das auch so ist.. könnte man darüber noch diskutieren aber dann ist auch schon die büchse geöffnet.