Ist besser Show () + Hide () oder SetVisible (Bool sichtbar)?

Was ist besser und warum? (Aus Sicht des Interface-Designs):

a) Zwei Show()und Hide()Funktionen haben

b) Eine SetVisible(bool visible)Funktion haben

BEARBEITEN: Zum Beispiel haben einige Objekte einen Sichtbarkeitsstatus und diese Funktion wird verwendet, um diesen zu ändern.

c) haben alle drei Show(), Hide(), SetVisible(bool visible)Funktionen

Ich bevorzuge SetVisible(bool visible), weil ich so Client-Code schreiben kann:

SetVisible(DetermineIfItShouldBeVisible());

anstatt schreiben zu müssen

if (DetermineIfItShouldBeVisible()) {
    Show();
} else {
    Hide();
}

Der SetVisibleAnsatz kann auch eine einfachere Implementierung ermöglichen. Wenn beispielsweise eine bestimmte konkrete Klasse die Methode einfach an ihre zusammengesetzten Klassen delegiert, SetVisiblebedeutet dies, dass eine Methode weniger implementiert werden muss.

void ButtonWithALabel::SetVisible(bool visible) {
    myButton.SetVisible(visible);
    myLabel.SetVisible(visible);
}

Ich bin nicht einverstanden mit allen Postern, die mehrere Funktionen vorschlagen, um dasselbe zu tun, ist eine gute Sache. Während drei Funktionen anstelle eines vielleicht nicht viel aufblasen scheinen, denken Sie daran , dass Ihre Klasse wahrscheinlich mit vielen solcher Funktionen , um am Ende (zB setEnabled, enable, disable) und damit dieser Ansatz wird mit einem am Ende viel größeren Klasse - Schnittstelle. Darüber hinaus ist es wahrscheinlich, dass Sie am Ende eine Reihe von ähnlich klingenden Funktionen / Eigenschaften / was auch immer in Ihrer Klasse haben, und die Multiplikation von Funktionen wird weiter verdecken, welche zu was gehört.

In Sprachen, die Eigenschaften unterstützen, sollten diese bevorzugt werden. Da dies jedoch weder in Java noch in C ++ der Fall ist, ist dies vermutlich ein strittiger Punkt.

Ich denke, setVisible()sollte aus folgenden Gründen bevorzugt werden:

1. Es ist sofort klar, was die Umkehrfunktion ist. Umzukehren setVisible(false)nennt man setVisible(true)hingegen das Gegenteil von hide()könnte leicht sein reveal().
2. Es ist programmgesteuert einfacher, wenn Sie festlegen, welchen Status der Code annehmen soll, dh Sie können setVisible(wantToSee)eine ifAnweisung aufrufen, anstatt sie zu verwenden .
3. Sobald Sie mehrere ähnliche Funktionen haben, wird das setX()Format verallgemeinert, sodass Sie eine Reihe von konsistenten Funktionen haben können, während der verbale Ansatz eine Vielzahl von Funktionen hervorbringt, die möglicherweise schwer zu finden sind, wenn Sie nicht wissen, wonach Sie suchen. Die Konsistenz der APIs erleichtert das Lernen und Merken erheblich.

Es hängt davon ab , welche Ein- und Ausblenden bedeutet im Kontext. Zuerst möchten Sie herausfinden, welches Ihr "Hauptweg" ist, und sich darauf konzentrieren, Folgendes zu entwickeln:

• Gründe für die Wahl setVisible(bool)
  • Es ist nur ein einfacher Bit-Flip, oder Ihr Objekt befindet sich hauptsächlich im Haltezustand
  • Ihr Objekt wird die meiste Zeit in einem CRUD-Framework verbringen
  • Zwischen dem Ein- und Ausblenden gibt es eine Menge einfach zu teilenden Codes
• Gründe zu wählen show()undhide()
  • Es werden wichtige Nebeneffekte oder viel Logik ausgeführt, z. B. wenn das Objekt alle Container auf ihren Sichtbarkeitsstatus überprüfen muss oder eine Übergangsanimation auslöst.
  • Ist es Teil eines Domain-Modells, bei dem das Ausdrücken von Absichten wichtig ist?

OK, jetzt, da Sie den "Goldstandard" -Kern codiert haben, müssen Sie herausfinden, ob es sich lohnt, dünne Convenience-Methoden in den anderen Stil einzufügen, um das Leben für jeden zu erleichtern, der Ihr Objekt verwenden möchte.

• Bequemlichkeit von setVisible(bool)
  • Ermöglicht das Vermeiden von if-Anweisungen, die triviale Bedingungen haben und nur die Sichtbarkeit beeinflussen (z. B. setVisible(a==b))
  • Kann in bestimmte Get- / Setter-Frameworks eingebunden werden, wenn dies zu erwarten ist
• Bequemlichkeit von show()undhide()
  • Nützlich in einer Sprache mit erstklassigen Funktionen und Rückrufen (z. B. onSuccess(widget.show))
  • Viel einfacher zu lesen mit Stack-Traces und Leistungsprofilen, da Sie schnell sehen können, was das Programm versucht hat

TLDR: Finden Sie heraus, welches das wichtigste ist, implementieren Sie es und fragen Sie sich, ob es sich lohnt, den anderen Stil als Thin-Convenience-Methode hinzuzufügen.

Ich würde "alle drei" sagen.

Show()und Hide()sind in der Regel leichter zu fassen als SetVisible(true)und SetVisible(false). Wenn Sie die Sichtbarkeit jedoch logisch festlegen möchten, ist es besser, eine Methode zu verwenden, die eine boolannimmt, als eine ifum diese herum zu konstruieren bool.

Sie können alle drei unterstützen, ohne Logik und minimale Boilerplate zu duplizieren:

void Show() {
    foo.Show();
    bar.Show();
}

void Hide() {
    foo.Hide();
    bar.Hide();
}

void SetVisible(bool visible) {
    if (visible) {
        Show();
    } else {
        Hide();
    }
}

Alternativ, wenn die Dinge, die Sie verpacken, eine mehr SetVisible-ish API haben:

void Show() {
    SetVisible(true);
}

void Hide() {
    SetVisible(false);
}

void SetVisible(bool visible) {
    foo.SetVisible(visible);
    bar.SetVisible(visible);
}

Ich bevorzuge show () und hide (). Tatsächlich kann jede Methode, die einen Booleschen Wert erhält, durch zwei Methoden geändert werden, um die Absicht der API besser auszudrücken. Zum Beispiel empfiehlt Robert Martin in sauberem Code, Methoden mit null Argumenten gegenüber Methoden mit einem Argument vorzuziehen.

Ein weiteres wichtiges Argument für mich ist die Lesbarkeit. Meiner Meinung nach kann guter Code wie Prosa gelesen werden. Seine wirklich seltsame Prosa ist etwa "main_window setVisible false" anstelle von "main_window hide". Sie schreiben oder sprechen normalerweise so. Warum verwenden Sie dieses seltsame Argument? Sprachkonstruktion in Softwareprogrammen Wann ist es durchaus möglich, eine natürlichere Sprache zu verwenden?

Ich glaube, je aussagekräftiger die Methode ist, desto lesbarer und folglich wartbarer wird der Code sein. Betrachten Sie die folgenden zwei Fälle:

Fall 1:

void showCustomerData(customerId){
  Customer customer = getCustomer(CustomerId);
  customerPanel.setVisible(customer.isCustomerEnabled());
}

Fall 2:

void showCustomerData(customerId){
  Customer customer = getCustomer(CustomerId);
  //always show customer panel
  customerPanel.setVisible(true);
}

Im ersten Fall ist klar, was die Funktion "setVisible" tut, aber wenn Sie es lesen möchten, würden Sie sagen:

Setzen Sie das Kundenbedienfeld auf sichtbar, wenn der Kunde aktiviert ist, oder auf ausgeblendet, wenn der Kunde deaktiviert ist.

Während es aussagekräftiger ist zu sagen:

• Überprüfen Sie den Status des Kunden:
  • Wenn der Kunde aktiviert ist, wird das Kundenfenster angezeigt
  • ansonsten verstecke es

Dadurch wird die Funktion "Fall 1" folgendermaßen geändert:

void showCustomerData(customerId){
  Customer customer = getCustomer(CustomerId);
  if(customer.isCustomerEnabled()){
    customerPanel.Show();
  }
  else{
    customerPanel.Hide();
  }
}

Es erzeugt mehr Code, ist aber besser lesbar.

Der zweite Fall hat einen offensichtlichen Fehler: Sie wissen bereits, dass Sie das Panel anzeigen möchten. Warum also nicht die Funktion "Anzeigen" verwenden?

Ich sage nicht, dass die Verwendung von "setVisible" absolut falsch ist, aber es wird verwirrend, wenn Sie versuchen, Code zu lesen, den Sie im Laufe der Zeit nicht geschrieben haben, und er entspricht nicht der Regel "Eine Funktion sollte nur eine Operation ausführen".

Ich glaube, dass die Hide()/ Show()alternative attraktiv ist, weil es einfacher ist zu verstehen, was los ist, als mit SetVisible(true), während eine einzelne Funktion vorzuziehen ist, weil es viele Bedingungen vermeidet.

Wenn das der Fall ist, schlage ich vor, eine Aufzählung als Eingabe zu verwenden SetVisible, damit Sie entweder SetVisible(Visibility.Visible)oder erhalten SetVisible(Visibility.Hidden). Sie haben eine einzelne Funktion, mit der Sie sofort ablesen können, welche Aktion ausgeführt wird.

Mit Javas Namenskonventionen hätten Sie vielleicht setVisible(Visibility.VISIBLE)oder setVisible(Visibility.HIDDEN).

Ich stimme Dariens Antwort zu, wollte aber einen Standpunkt aus der Perspektive eines C # -Programmierers hinzufügen.

Wenn ich Code sehe, der 'setXXX' sagt, habe ich gelesen, dass es einen Wert für ein Objekt festlegt. Ich erwarte jedoch keine anderen Nebenwirkungen als das Festlegen dieses Werts, und ich erwarte, dass dies idempotent ist (dh ich kann es mit dem gleichen Wert einstellen und es ist in Ordnung). Es ist eher so, als würde man auf ein Feld zugreifen. Im Allgemeinen würde ich auch eine 'getXXX'-Methode zusammen mit einer' setXXX'-Methode erwarten.

Ich weiß nicht, ob dies das ist, was Sie in Java und C ++ erwarten, aber das ist, was ich in C # erwarten würde, obwohl es in C # eine Kurzform für diese Eigenschaft gibt, die Properties heißt. Und hier finden Sie einige nützliche Anleitungen zur Verwendung von Eigenschaften ( http://msdn.microsoft.com/en-us/library/ms182181.aspx ).

In Anbetracht dieser Ansicht hängt die von mir gewählte Benutzeroberfläche nur davon ab, ob es Nebenwirkungen gibt (außer dem Ändern dieses Feldwerts):

Wenn das Ausführen der Aktion Nebenwirkungen hat, z. B. ein Dialogfeld angezeigt wird, würde ich mit "Show ()" und "Hide ()" fortfahren.

Wenn es keine Nebenwirkungen hat, sagen wir, ich stelle die Sichtbarkeit eines "Widgets" ein und etwas anderes rendert das Widget abhängig von seinem Status, dann würde ich setVisibility oder setIsVisible verwenden. (Ich würde es nicht SetVisible nennen).

In C # (bei Java nicht sicher) wird häufig ein Beobachtermuster verwendet, bei dem ein UI-Framework auf Änderungen an Objekten wartet und die Benutzeroberfläche automatisch neu rendert, wenn sich eine Eigenschaft wie Visibility ändert. Das bedeutet, dass das Setzen des Werts durch Aufrufen von setIsVisible so aussieht, als hätte es Nebenwirkungen, in meiner Definition jedoch nicht. Der Vertrag des Widgets wird erfüllt, indem der Feldwert auf "IsVisible" gesetzt wird.

Anders ausgedrückt ist es in Ordnung, die Sichtbarkeit einer Beschriftung in einem Formular zu ändern, bevor das Formular angezeigt wird. Dh label.getIsVisible == true, aber das Formular wird nicht angezeigt.

Es ist nicht in Ordnung, Hide () aufzurufen, wenn das Formular nicht angezeigt wird.

Ich würde ein leicht modifiziertes Interface vorschlagen:

Show();
Hide();
ToggleVisible();
ToggleVisible(bool visible);

Bessere Namen

Diese Methodennamen helfen dem Entwickler bei der Entscheidung, welche Methode basierend auf den durchzuführenden Schritten verwendet werden soll. Während SetVisible(bool visible)ein Entwickler verwirren kann, weil er die gleiche semantische Bedeutung wie Show()und vermittelt Hide(), Toggle()impliziert dies die Existenz einer Bedingung, die die Aktion bestimmt. Für den Entwickler wird es somit intuitiv, wann jede Methode anzuwenden ist.

Reduzierte Code-Redundanz

Der Vorteil der Verwendung mehrerer Methoden in Ihrer Schnittstelle besteht darin, dass der aufrufende Code vereinfacht wird. Sie könnten nur Show()und aussetzen Hide(), aber:

• Sie würden wahrscheinlich eine SetVisible()private Methode benötigen, um die eigentliche Arbeit hinter den Kulissen zu erledigen (oder redundanten Code für Show()und zu schreiben Hide()).
• Der aufrufende Code enthält möglicherweise viele redundante if / else-Blöcke, um die zu verwendende Methode auszuwählen. Das bläht meiner Meinung nach den Code auf.
• Wenn ich der Verbraucher wäre, würde ich wahrscheinlich nur meine eigene Wrapper-Funktion schreiben, die das tut, was SetVisible()(oder Toggle()) bereits tut, um ein Aufblähen des Codes zu vermeiden (ich hasse redundanten Code). So duplizieren Sie eine Methode, die wahrscheinlich bereits als private Methode in der Implementierung vorhanden ist.

Ich würde nur empfehlen, SetVisible(bool)wenn die Sichtbarkeit zweimal umgeschaltet wird (Anzeigen und erneutes Ausblenden oder Verbergen und erneutes Anzeigen), die Dinge im Wesentlichen im gleichen Zustand wie vor der Durchführung der Operation zu belassen (in Ordnung, wenn Anzeigen und erneutes Ausblenden) etwas oder umgekehrt hinterlässt Objekte, die neu gezeichnet werden müssen, vorausgesetzt, es kann damit gerechnet werden, dass dies "automatisch" geschieht. Wenn das Ausblenden und Anzeigen eines Objekts keine anderen Auswirkungen hat als das Ändern eines Statusbits, ist es für externen Code sinnvoll, über Methoden zu verfügen, die einen Sichtbarkeitsparameter akzeptieren, und das Schreiben eines solchen Codes wird durch erleichtert SetVisible.

Wenn das Ausblenden und Wiedereinblenden eines Objekts Nebenwirkungen haben kann, z. B. das Ändern der Z-Reihenfolge, sollten solche Aktionen mit größerer Wahrscheinlichkeit mit separaten Methoden ausgeführt werden. In solchen Fällen ist die Nützlichkeit von externen Methoden, die einen "Sichtbarkeit" -Parameter akzeptieren, begrenzt, und daher ist es wenig vorteilhaft, sie zu vereinfachen. Ferner wird eine SetVisibleMethode (fälschlicherweise) vorschlagen, dass Änderungen an der Sichtbarkeit von Objekten ohne Nebenwirkungen durchgeführt werden können.