Est-ce que better Show () + Hide () ou SetVisible (bool visible)?

Quoi de mieux et pourquoi? (Du point de vue de la conception de l'interface):

a) Avoir deux Show()et Hide()fonctions

b) Avoir une SetVisible(bool visible)fonction

EDIT: Par exemple, certains objets ont un état de visibilité et cette fonction est utilisée pour le changer.

c) Pour avoir tous les trois Show(), Hide(), SetVisible(bool visible)fonctions

Je préfère SetVisible(bool visible), car cela me permet d'écrire le code client comme ceci:

SetVisible(DetermineIfItShouldBeVisible());

au lieu d'avoir à écrire

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

L' SetVisibleapproche peut également permettre une mise en œuvre plus facile. Par exemple, si une classe concrète particulière délègue simplement la méthode à ses classes composites, cela SetVisiblesignifie une méthode de moins à implémenter.

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

Je suis en désaccord avec toutes les affiches suggérant que plusieurs fonctions pour faire la même chose est une bonne chose. Alors que trois fonctions au lieu d'un peut ne pas sembler beaucoup ballonnement, rappelez - vous que votre classe est susceptible de se retrouver avec beaucoup de ces fonctions (par exemple setEnabled, enable, disable) et donc cette approche va se retrouver avec une grande interface plus grande classe. De plus, il est probable que vous obtiendrez un tas de fonctions / propriétés / similaires similaires dans votre classe et que la multiplication de fonctions obscurcira davantage le choix.

Dans les langages qui supportent les propriétés, celles-ci devraient être préférées, mais comme ni Java ni C ++ ne le font, je suppose que c'est un point discutable.

Je pense que setVisible()devrait être préféré pour ces raisons:

1. La fonction inverse est immédiatement évidente. Pour inverser setVisible(false)votre appel setVisible(true)alors que le contraire de hide()pourrait être facilement reveal().
2. C'est plus simple, du point de vue du programme, à chaque fois que vous déterminez quel état il doit recevoir en code, c'est-à-dire que vous pouvez appeler setVisible(wantToSee)plutôt que d'utiliser une ifinstruction.
3. Une fois que vous avez plusieurs fonctions similaires, le setX()format se généralise afin que vous puissiez avoir un ensemble de fonctions cohérentes, tandis que l’approche verbed engendre une foule de fonctions qui peuvent être difficiles à localiser si vous ne savez pas ce que vous recherchez. La cohérence des API facilite considérablement leur apprentissage et leur mémorisation.

Cela dépend de ce que montrer et cacher signifie dans le contexte. D'abord, vous voulez savoir lequel est votre "voie principale" et vous concentrer sur le développement de cela:

• Raisons pour choisir setVisible(bool)
  • Il ne s'agit que d'un simple basculement, ou votre objet est principalement en attente
  • Votre objet va passer le plus clair de son temps dans un cadre CRUD
  • Il y a beaucoup de code facile à partager entre l'affichage et le masquage
• Raisons pour choisir show()ethide()
  • Il y a des effets secondaires importants ou beaucoup de logique en cours d' exécution, comme lorsque l'objet doit vérifier tous ses conteneurs pour leur état de visibilité, ou déclenche une animation de transition.
  • Fait-il partie d'un modèle de domaine où l'expression de l' intention est importante

OK, alors maintenant que vous avez codé le noyau «standard d’or», vous devez déterminer s’il vaut la peine d’ajouter des méthodes simples dans l’autre style, afin de faciliter la vie de ceux qui vont utiliser votre objet.

• Commodité de setVisible(bool)
  • Vous permet d'éviter les instructions si qui ont des conditions triviales et n'affectent que la visibilité (ex. setVisible(a==b))
  • Peut être connecté à certains frameworks getter / setter, si vous vous attendez à quelque chose
• Commodité de show()ethide()
  • Utile dans une langue avec des fonctions de première classe et des rappels (ex. onSuccess(widget.show))
  • Beaucoup plus facile à lire avec les traces de pile et le profilage de performance, car vous pouvez rapidement voir ce que le programme essayait de faire

TLDR: Trouvez lequel est le plus important, mettez-le en œuvre, puis demandez-vous s'il vaut la peine d'ajouter l'autre style en tant que méthodes simples.

Je dirais "tous les trois".

Show()et Hide()ont tendance à être plus facile à parler que SetVisible(true)et SetVisible(false). Toutefois, lorsque vous souhaitez définir la visibilité de manière logique, il est préférable d’avoir une méthode utilisant une méthode boolplutôt qu’une construction ifautour de celle-ci bool.

Vous pouvez prendre en charge les trois sans dupliquer la logique et le passe-partout minimal:

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

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

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

Alternativement, si les choses que vous enveloppez ont une SetVisibleAPI plus rapide:

void Show() {
    SetVisible(true);
}

void Hide() {
    SetVisible(false);
}

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

Je préfère show () et hide (). En fait, chaque méthode qui reçoit un booléen peut être modifiée pour deux méthodes mieux exprimer l'intention de l'API. Par exemple, Robert Martin, dans un code épuré, recommande de préférer les méthodes avec zéro argument aux méthodes avec un seul argument.

Un autre argument important pour moi est la lisibilité. À mon avis, un bon code peut être lu comme une prose, c'est une prose vraiment étrange du genre "main_window setVisible false" au lieu de "main_window hide", vous écrivez ou parlez comme ça normalement ?, pourquoi utiliser cet étrange construction du langage dans les logiciels quand est-il parfaitement possible d'utiliser un langage plus naturel?.

Je pense que plus la méthode est expressive, plus le code sera lisible et, par conséquent, maintenable. Considérons les deux cas suivants:

Cas 1:

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

Cas 2:

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

Dans le premier cas, la fonction "setVisible" est claire, mais si vous voulez la lire, vous diriez:

définissez le panneau client sur visible si le client est activé ou définissez-le sur masqué si le client est désactivé.

Bien qu'il soit plus descriptif de dire:

• vérifier le statut du client:
  • si le client est activé, affichez le panneau du client
  • sinon, cachez-le

ce qui modifiera la fonction "Cas 1" comme suit:

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

il produit plus de code, mais est plus lisible.

Le second cas a un défaut évident: vous savez déjà que vous souhaitez afficher le panneau, alors pourquoi ne pas utiliser la fonction "Afficher"?

Je ne dis pas que l'utilisation de "setVisible" est absolument fausse, mais cela devient confus lorsque vous essayez de lire du code que vous n'avez pas écrit au fil du temps et qu'il n'est pas conforme à la règle "Une fonction ne doit effectuer qu'une seule opération".

Je crois que la Hide()/ Show()alternative est intéressante , car il est plus facile de comprendre ce qui se passe qu'avec SetVisible(true), tout en ayant une seule fonction est préférable car il évite beaucoup de conditionals.

Si c'est le cas, je suggère d'utiliser une énumération comme entrée SetVisible, afin que vous obteniez l'un SetVisible(Visibility.Visible)ou l' autre SetVisible(Visibility.Hidden). Vous avez une seule fonction que vous pouvez lire instantanément quelle action est entreprise.

En utilisant les conventions de nommage de Java, vous auriez peut-être setVisible(Visibility.VISIBLE)ou setVisible(Visibility.HIDDEN).

Je suis d'accord avec la réponse de Darien, mais je voulais ajouter un point de vue du point de vue des programmeurs C #.

Quand je vois du code qui dit 'setXXX', je lis cela pour dire qu'il donne une valeur à une chose, je ne m'attends pas à ce que cela ait des effets secondaires sur cette chose à part définir cette valeur, et je pense que ce sera idempotent. (c.-à-d. que je peux continuer à le régler avec la même valeur et ce n'est pas grave). C'est un peu comme accéder à un champ. Généralement, je m'attendrais aussi à voir une méthode 'getXXX' avec un 'setXXX'.

Je ne sais pas si c'est ce à quoi vous vous attendiez en Java et en C ++, mais c'est ce à quoi je m'attendrais en C #, bien qu'en C #, il existe un raccourci pour cela appelé Propriétés. Et voici quelques conseils utiles sur l'utilisation des propriétés ( http://msdn.microsoft.com/en-us/library/ms182181.aspx ).

Compte tenu de ce point de vue, l'interface que je choisirais dépend uniquement des effets secondaires (autres que la modification de la valeur de ce champ):

Si cette action a des effets secondaires, par exemple si une boîte de dialogue est affichée, alors je choisirais "Show ()" et "Hide ()".

S'il n'a pas d'effets secondaires, si je règle la visibilité d'un "widget" et si un autre rendu le rend en fonction de son état, j'utiliserais setVisibility ou setIsVisible. (Je n'appellerais pas cela SetVisible).

En C # (pas sûr de Java), il est assez courant d’adopter un motif observateur, dans lequel un cadre d’interface utilisateur écoute les modifications apportées aux objets et restitue automatiquement l’interface utilisateur lorsqu’une propriété, telle que Visibility, change. Cela signifie que définir la valeur en appelant setIsVisible apparaît comme si elle avait des effets secondaires, mais pas dans ma définition. Le contrat du widget est rempli en définissant sa valeur de champ représentant "IsVisible".

En d'autres termes, je peux activer / désactiver la visibilité d'une étiquette sur un formulaire avant que celui-ci ne soit affiché. C'est-à-dire label.getIsVisible == true, mais le formulaire n'est pas affiché.

Je ne peux pas appeler Hide () lorsque le formulaire n'est pas affiché.

Je suggérerais une interface légèrement modifiée:

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

Meilleurs noms

Ces noms de méthodes aident le développeur à choisir la méthode à utiliser en fonction de ce qui doit être fait. Considérant que SetVisible(bool visible)peut confondre un développeur, car il transmet la même signification sémantique que Show()et Hide(), Toggle()implique l'existence d'une condition qui détermine l'action. Il devient donc intuitif pour le développeur d’utiliser chaque méthode.

Redondance de code réduite

L'avantage d'avoir plusieurs méthodes dans votre interface est que cela simplifie le code d'appel. Vous pouvez simplement exposer Show()et Hide(), mais:

• Vous auriez probablement besoin d'une sorte de SetVisible()méthode privée pour faire le vrai travail dans les coulisses (ou écrire du code redondant pour Show()et Hide()).
• Le code appelant peut contenir de nombreux blocs if / else redondants pour choisir la méthode à utiliser. Cela gonfle le code à mon avis.
• Si j'étais le consommateur, j'écrirais probablement juste ma propre fonction wrapper qui fait ce SetVisible()(ou Toggle()) déjà déjà afin d'éviter le gonflement du code (je déteste le code redondant). On duplique ainsi une méthode qui existe probablement déjà en tant que méthode privée dans la mise en œuvre.

Je suggérerais d'utiliser le SetVisible(bool)cas échéant uniquement si le fait de changer la visibilité deux fois (afficher et masquer, ou masquer et afficher à nouveau) laisserait les choses dans le même état qu'avant l'opération (c'est bien si afficher et masquer Quelque chose ou vice-versa laisse des objets nécessitant un redessin, à condition que l'on peut s'attendre à ce qu'il se produise "automatiquement"). Si masquer et afficher un objet n'aura d'autre effet que de changer un bit d'état, il serait logique que du code extérieur ait des méthodes acceptant un paramètre de visibilité, et l'écriture de ce code sera facilitée SetVisible.

Si le fait de cacher et de montrer à nouveau un objet peut avoir des effets secondaires, tels que la modification de l'ordre des Z, ces actions doivent probablement être effectuées par des méthodes distinctes. Dans de tels cas, l'utilité des méthodes extérieures qui acceptent un paramètre de "visibilité" sera limitée, de sorte qu'il sera peu avantageux de les faciliter. De plus, une SetVisibleméthode suggérera (à tort) que des changements dans la visibilité des objets peuvent être accomplis sans effets secondaires.