4. if-else welche Variante ist besser?

if-else welche Variante ist besser?

  • K

    audacia schrieb:

    Viel wichtiger als "so kurz wie möglich" ist "so wenig Redundanz wie möglich". In diesem Sinne würde ich auf deine Initialfrage auch mit "sie sind beide gleich schlecht" antworten 😉 Du solltest dein Problem möglichst anders lösen.[...]

    Sehr weise, aber leider etwas unkonkret... ich bin etwas überfragt, wie ich die geposteten Codeschnipsel besser/anders umsetzen soll!?

    audacia schrieb:

    [...](Noch kurz zu den Geschwindigkeitsunterschieden: Variante 2 ist sicherlich effizienter. Aber darüber denkst du nur nach, bis du weißt, was ein Aufruf von TRadioButton::SetChecked() oder TControl::SetEnabled() kostet. Wenn es dich interessiert, kannst du ja mal im Debug-Modus in den VCL-Code steppen.)

    😮 Alter Schwede!!! 😮

    0
  • W

    Kolumbus schrieb:

    Sehr weise, aber leider etwas unkonkret... ich bin etwas überfragt, wie ich die geposteten Codeschnipsel besser/anders umsetzen soll!?

    Ich habe mich aber auch gefragt wozu Du die beiden booleans benötigst, zumal Du mit zwei boolean-Variablen zusammen zwei Zustände darzustellen scheinst. Hängen denn noch mehr Controls von "Entscheidungsvariable" ab? Dann könntest Du Dir mal das Statusmuster anschauen.

    0
  • A

    Kolumbus schrieb:

    Sehr weise, aber leider etwas unkonkret...

    Ebenso 😉
    Für diese Entscheidung sind mir "Entscheidungsvariable", "RadBtnB1" und "RadBtnA1" zu abstrakt. Falls du auf dieser Abstraktion beharrst, so bekommst du auch nur allgemeine Ratschläge:

    • Wäre es nicht vielleicht sinnvoller, zwei RadioGroups zu benutzen und diese wechselseitig zu deaktivieren?
    • Wie witte sagte: warum speicherst du einen Zustand (bRadBtnAEnabled, bRadBtnBEnabled), den bereits die entsprechende Komponente für dich speichert? (Und bevor du fragst, die entsprechende Operation ist nicht einmal teuer:
    // Controls.pas, Z. 4844ff
function TControl.GetEnabled: Boolean;
begin
  Result := FEnabled;
end;

    ;))

    0
  • K

    Ich melde mich demnächst in diesem Thread zurück... ich habe leider gerade ein anderes Problem!

    0
  • K

    witte schrieb:

    [...]Ich habe mich aber auch gefragt wozu Du die beiden booleans benötigst, zumal Du mit zwei boolean-Variablen zusammen zwei Zustände darzustellen scheinst.

    Der Teil des Formulars auf dem sich die RadioButtons und noch viele weitere Controls befinden, wird zwischenzeitlich komplett deaktiviert und ich muss hinterher noch wissen, welche Controls aktiv waren ;o)

    witte schrieb:

    [...] Hängen denn noch mehr Controls von "Entscheidungsvariable" ab? Dann könntest Du Dir mal das Statusmuster anschauen.

    ja, von meiner "Entscheidungsvariablen" hängen noch mehr Controls ab! Was ist Statusmuster?

    Edit: Die Forumsuche spuckt zu "Statusmuster" nur diesen Thread hier aus... Herzlichen Glückwunsch für die 1. Verwendung dieses Wortes hier im Forum. 🤡

    0
  • W

    O.K. ich habe Zustand ungeschickt übersetzt:
    http://de.wikipedia.org/wiki/Zustand_(Entwurfsmuster)

    Ich benutze das Muster häufig, wenn das Form in verschiedene Zustände versetzt werden muß Readonly->Anfügen->Bearbeiten oder bei Implementierung von Benutzerrechten. Du mußt mal prüfen wieweit der Implementierungsaufwand sich lohnt.

    0
  • K

    witte schrieb:

    [...]http://de.wikipedia.org/wiki/Zustand_(Entwurfsmuster)
    [...] Du mußt mal prüfen wieweit der Implementierungsaufwand sich lohnt.

    Schon dabei, das mal abzuschätzen. Wirklich interessante Herangehensweise... Das Programm wird zwar dadurch größer, aber um Einiges schneller. Sollte man GoF gelesen haben?

    audacia schrieb:

    Wäre es nicht vielleicht sinnvoller, zwei RadioGroups zu benutzen [...]

    Danke für den Tip - das habe ich übersehen 🙂

    audacia schrieb:

    Viel wichtiger als "so kurz wie möglich" ist "so wenig Redundanz wie möglich". In diesem Sinne würde ich auf deine Initialfrage auch mit "sie sind beide gleich schlecht" antworten 😉 Du solltest dein Problem möglichst anders lösen.

    Dazu nochmal: hattest du es im Endeffekt auch auf witte's Vorschlag abgesehen?

    0
  • K

    Entwurfsmuster... für jeden komplexen Zustand einer Komponente eine eigene Komponente... Ich denke ich werde es mal testen... Da ich die meisten Controls auf Panels angeordnet habe, lässt sich das relativ unkompliziert handhaben.

    0
  • A

    Kolumbus schrieb:

    audacia schrieb:

    Viel wichtiger als "so kurz wie möglich" ist "so wenig Redundanz wie möglich". In diesem Sinne würde ich auf deine Initialfrage auch mit "sie sind beide gleich schlecht" antworten 😉 Du solltest dein Problem möglichst anders lösen.

    Dazu nochmal: hattest du es im Endeffekt auch auf witte's Vorschlag abgesehen?

    Nein, ich hatte es auf nichts direkt abgesehen. Ich schrieb ja, daß mir dein Beispiel zu wenig konkret ist, als daß ich ein alternatives Design vorschlagen könnte. Aber das State-Pattern ist da sicherlich anwendbar.

    0
  • W

    Kolumbus schrieb:

    Entwurfsmuster... für jeden komplexen Zustand einer Komponente eine eigene Komponente...

    Ich dachte jetzt eigentlich, dass das Form einen member bekommt, welches einen Zustand repräsentiert und die Komponenten des Form darauf einstellt. Wenn der Zustand sich ändert wird das Zustandsobjekt ausgetauscht und dann mithilfe des neuen Objektes die Komponenten eingestellt. Diese Zustandsobjekte sollten dann friends zur Formklasse sein.

    0
Anmelden zum Antworten