it-swarm.com.de

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: Einige Objekte haben beispielsweise den Sichtbarkeitsstatus und werden mit diesen Funktionen geändert.

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

59
user3123061

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

SetVisible(DetermineIfItShouldBeVisible());

anstatt schreiben zu müssen

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

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

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

Ich bin nicht einverstanden mit allen Postern, die vorschlagen, dass mehrere Funktionen, um dasselbe zu tun, eine gute Sache sind. Während drei Funktionen anstelle von einer nicht sehr aufgedunsen erscheinen, denken Sie daran, dass Ihre Klasse wahrscheinlich viele solcher Funktionen hat (z. B. setEnabled, enable, disable) und Daher wird dieser Ansatz zu einer viel größeren Klassenschnittstelle führen. Darüber hinaus ist es wahrscheinlich, dass Sie am Ende eine Reihe ähnlich klingender Funktionen/Eigenschaften/was auch immer in Ihrer Klasse haben und die Multiplikation von Funktionen wird weiter verschleiern, welche zu was passt.

In Sprachen, die Eigenschaften unterstützen, sollten diese bevorzugt werden, aber da weder Java noch C++ dies tun, denke ich, ist das ein strittiger Punkt.

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

  1. Es ist sofort klar, was die Umkehrfunktion ist. Um setVisible(false) umzukehren, rufen Sie setVisible(true) auf, während das Gegenteil von hide() leicht reveal() sein könnte.
  2. Es ist programmgesteuert einfacher, wenn Sie festlegen, welchen Status der Code annehmen soll, d. H. Sie können setVisible(wantToSee) aufrufen, anstatt eine if -Anweisung zu verwenden.
  3. Sobald Sie mehrere ähnliche Funktionen haben, wird das Format setX() verallgemeinert, sodass Sie eine Reihe konsistenter Funktionen haben können, während der verbale Ansatz eine Vielzahl von Funktionen hervorbringt, die schwer zu finden sein können, wenn Sie nicht wissen, was Sie sind Auf der Suche nach. Die Konsistenz der APIs erleichtert das Erlernen und Erinnern erheblich.
35
Jack Aidley

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

  • Gründe für die Auswahl von 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
    • Es gibt eine Menge leicht zu teilenden Codes zwischen Ein- und Ausblenden
  • Gründe für die Auswahl von show() und hide()
    • Es werden wichtige Nebenwirkungen oder eine Menge Logik ausgeführt, z. B. wenn das Objekt alle Container auf ihren Sichtbarkeitsstatus überprüfen muss, oder löst eine Übergangsanimation aus.
    • Ist es Teil eines Domänenmodells, bei dem es wichtig ist, die Absicht auszudrücken?

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

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

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

19
Darien

Ich würde "alle drei" sagen.

Show() und Hide() sind in der Regel leichter zu erfassen als SetVisible(true) und SetVisible(false). Wenn Sie jedoch die Sichtbarkeit logisch festlegen möchten, ist es besser, eine Methode zu verwenden, die ein bool verwendet, als ein if um dieses bool zu erstellen.

Sie können alle drei unterstützen, ohne die Logik und die 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);
}
12
Garry Shutler

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

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

Unter Verwendung der Namenskonventionen von Java hätten Sie möglicherweise setVisible(Visibility.VISIBLE) oder setVisible(Visibility.HIDDEN).

5
Gabe

Ich bevorzuge show () und hide (). Tatsächlich kann jede Methode, die einen Booleschen Wert erhält, für 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 zu bevorzugen.

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

5
AlfredoCasado

Ich glaube, je ausdrucksstärker die Methode ist, desto lesbarer und folglich wartbarer ist der Code. 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 sie lesen möchten, würden Sie sagen:

setzen Sie das Kundenfenster 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
    • andernfalls verstecken Sie es

dadurch wird die Funktion "Fall 1" wie folgt 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 weist einen offensichtlichen Fehler auf: Sie wissen bereits, dass Sie das Bedienfeld 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, der nicht von Ihnen im Laufe der Zeit geschrieben wurde, und es entspricht nicht der Regel "Eine Funktion sollte nur eine Operation ausführen".

5
OKAN

Ich stimme Dariens Antwort zu, wollte aber einen Standpunkt aus Sicht der C # -Programmierer hinzufügen.

Wenn ich Code mit der Aufschrift "setXXX" sehe, habe ich diesen gelesen, um zu sagen, dass er einen Wert für eine Sache festlegt. Ich erwarte keine Nebenwirkungen in dieser Sache außer der Einstellung dieses Werts, und ich erwarte, dass dies idempotent ist (dh ich kann es weiterhin 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 'erwarten.

Ich weiß nicht, ob Sie dies in Java und C++) erwarten, aber das würde ich in C # erwarten, obwohl es in C # eine kurze Hand für diese Eigenschaft gibt. Und hier sind einige Gute Anleitung zur Verwendung von Eigenschaften ( http://msdn.Microsoft.com/en-us/library/ms182181.aspx ).

In dieser Ansicht hängt die von mir gewählte Schnittstelle nur davon ab, ob Nebenwirkungen auftreten (außer das Ändern dieses Feldwerts):

Wenn das Ausführen der Aktion Nebenwirkungen hat, zum Beispiel 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 dieses 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 Sichtbarkeit ändert. Das bedeutet, dass das Festlegen 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 "IsVisible" festgelegt wird.

Anders ausgedrückt, es ist in Ordnung, die Sichtbarkeit eines Etiketts auf einem Formular umzuschalten, 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.

3

Ich würde eine leicht modifizierte Oberfläche vorschlagen:

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

Bessere Namen

Diese Methodennamen helfen dem Entwickler bei der Entscheidung, welche Methode verwendet werden soll, basierend auf den erforderlichen Maßnahmen. Während SetVisible(bool visible) einen Entwickler verwirren kann, weil es dieselbe semantische Bedeutung wie Show() und Hide() vermittelt, impliziert Toggle() die Existenz einer Bedingung, die bestimmt die Aktion. Auf diese Weise wird es für den Entwickler intuitiv, wann jede Methode verwendet werden soll.

Reduzierte Code-Redundanz

Der Vorteil mehrerer Methoden in Ihrer Schnittstelle besteht darin, dass der aufrufende Code vereinfacht wird. Sie könnten einfach Show() und Hide() verfügbar machen, aber:

  • Sie würden wahrscheinlich eine Art SetVisible() private Methode benötigen, um die eigentliche Arbeit hinter den Kulissen zu erledigen (oder redundanten Code für Show() und Hide() schreiben).
  • Der aufrufende Code enthält möglicherweise viele redundante if/else-Blöcke, um nur die zu verwendende Methode auszuwählen. Dies bläht den Code meiner Meinung nach 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). . Duplizieren einer Methode, die wahrscheinlich bereits vorhanden als private Methode in der Implementierung ist.
2
gilly3

Ich würde vorschlagen, SetVisible(bool) zu verwenden, wenn überhaupt, wenn das zweimalige Umschalten der Sichtbarkeit (Ein- und Ausblenden oder Ausblenden und erneutes Einblenden) die Dinge im Wesentlichen im gleichen Zustand belassen würde wie vor dem Ausführen der Operation (es ist) gut, wenn beim Ein- und Ausblenden von Objekten oder umgekehrt Objekte neu gezeichnet werden müssen, sofern dies "automatisch" zu erwarten ist). Wenn das Ausblenden und Anzeigen eines Objekts keine andere Auswirkung hat als das Ändern eines Statusbits, ist es für externen Code sinnvoll, einige Methoden zu verwenden, die einen Sichtbarkeitsparameter akzeptieren, und das Schreiben eines solchen Codes wird durch SetVisible.

Wenn das Ausblenden und erneute Anzeigen eines Objekts Nebenwirkungen wie das Ändern der Z-Reihenfolge haben kann, sollten solche Aktionen eher mit separaten Methoden ausgeführt werden. In solchen Fällen ist die Nützlichkeit externer Methoden, die einen "Sichtbarkeit" -Parameter akzeptieren, begrenzt, so dass es wenig vorteilhaft ist, sie zu erleichtern. Ferner schlägt eine SetVisible -Methode (fälschlicherweise) vor, dass Änderungen an der Sichtbarkeit von Objekten ohne Nebenwirkungen durchgeführt werden können.

0
supercat