Czy lepsze jest Show () + Hide () lub SetVisible (bool widoczne)?

Co jest lepsze i dlaczego? (Z punktu widzenia projektowania interfejsu):

a) Mieć dwa Show()i Hide()funkcje

b) Aby mieć jedną SetVisible(bool visible)funkcję

EDYCJA: Na przykład niektóre obiekty mają stan widoczności i ta funkcja służy do jego zmiany.

c) wszystkie trzy Show(), Hide(), SetVisible(bool visible)funkcje

Wolę SetVisible(bool visible), ponieważ pozwala mi pisać kod klienta w następujący sposób:

SetVisible(DetermineIfItShouldBeVisible());

zamiast pisać

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

SetVisiblePodejście może również umożliwić łatwiejsze wdrożenie. Na przykład, jeśli konkretna konkretna klasa po prostu deleguje metodę do swoich klas złożonych, SetVisibleoznacza to, że należy wdrożyć jedną metodę mniej.

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

Nie zgadzam się ze wszystkimi plakatami sugerującymi, że wiele funkcji do robienia tego samego jest dobrą rzeczą. Podczas gdy trzy funkcje zamiast jednego nie może wydawać się dużo wzdęć, pamiętaj, że twoja klasa jest prawdopodobne, aby skończyć z wielu takich funkcji (np setEnabled, enable, disable), a zatem tego podejścia będzie skończyć z dużo większej interfejsu klasy. Co więcej, jest prawdopodobne, że skończysz z wieloma podobnymi brzmiącymi funkcjami / właściwościami / czymkolwiek w twojej klasie, a mnożenie funkcji dodatkowo zaciemni, która z nich idzie z czym.

W językach, które obsługują właściwości, powinny być preferowane, ale skoro ani Java, ani C ++ nie robią tego, myślę, że to kwestia sporna.

Myślę, że setVisible()należy preferować z następujących powodów:

1. Od razu widać, czym jest funkcja odwrotna. Aby odwrócić setVisible(false), zadzwoń, setVisible(true)podczas gdy przeciwieństwo hide()może być z łatwością reveal().
2. Jest programowo prostszy za każdym razem, gdy określasz, który stan powinien przyjąć w kodzie, tzn. Możesz zadzwonić setVisible(wantToSee)zamiast używać ifinstrukcji.
3. Gdy masz wiele podobnych funkcji, setX()format uogólnia, dzięki czemu możesz mieć zestaw spójnych funkcji, podczas gdy podejście sprawdzane tworzy wiele funkcji, które mogą być trudne do zlokalizowania, jeśli nie wiesz, czego szukasz. Spójność interfejsów API znacznie ułatwia ich naukę i zapamiętywanie.

To zależy od tego, co Wyświetlanie i ukrywanie oznacza w kontekście. Najpierw chcesz dowiedzieć się, który z nich jest Twoją „główną drogą” i skupić się na rozwijaniu tego:

• Powody, dla których warto wybrać setVisible(bool)
  • Jest to zwykły bit-flip, lub twój obiekt głównie trzyma stan
  • Twój obiekt będzie spędzał większość czasu w środowisku CRUD
  • Istnieje wiele łatwo udostępnianych kodów między pokazywaniem a ukrywaniem
• Powody wyboru show()ihide()
  • Występują ważne skutki uboczne lub dużo logiki, na przykład gdy obiekt musi sprawdzić wszystkie swoje kontenery pod kątem ich widoczności lub uruchamia animację przejścia.
  • Czy jest to część modelu domeny, w którym ważne jest wyrażanie intencji

OK, więc teraz, gdy już zakodowałeś jej „złoty standard”, musisz dowiedzieć się, czy warto dodać cienkie metody wygody w innym stylu, aby ułatwić życie każdemu, kto będzie używał twojego obiektu.

• Wygoda setVisible(bool)
  • Pozwala uniknąć instrukcji if, które mają trywialne warunki i wpływają tylko na widoczność (np. setVisible(a==b))
  • Może być podłączony do pewnych struktur getter / setter, jeśli jest to coś, czego się spodziewasz
• Wygoda show()ihide()
  • Przydatny w języku z pierwszorzędnymi funkcjami i funkcjami zwrotnymi (np. onSuccess(widget.show))
  • Znacznie łatwiejszy do odczytania dzięki stosom śledzenia i profilowaniu wydajności, ponieważ można szybko zobaczyć, co program próbował zrobić

TLDR: Dowiedz się, który jest najważniejszy, zaimplementuj go, a następnie zadaj sobie pytanie, czy warto dodać drugi styl jako metody cienkiej wygody.

Powiedziałbym „wszystkie trzy”.

Show()i Hide()wydają się być łatwiejsze do odczytania niż SetVisible(true)i SetVisible(false). Jednak, jeśli chcesz ustawić logiczność widoczności, lepiej jest mieć metodę przyjmującą boolzamiast budować ifwokół niej bool.

Możesz obsłużyć wszystkie trzy bez powielania logiki i minimalnej płyty kotłowej:

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

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

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

Alternatywnie, jeśli rzeczy, które SetVisiblepakujesz, mają bardziej zaawansowany interfejs API:

void Show() {
    SetVisible(true);
}

void Hide() {
    SetVisible(false);
}

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

Wolę show () i hide (), w rzeczywistości każda metoda, która odbiera jedną wartość logiczną, może zostać zmieniona dla dwóch metod, aby lepiej wyrażać intencję API. Na przykład Robert Martin w czystym kodzie poleca metody wolniejsze od zerowych argumentów od metod z jednym argumentem.

Innym ważnym argumentem jest dla mnie czytelność, moim zdaniem dobry kod można odczytać jak prozę, jego naprawdę dziwna proza ​​coś takiego jak „main_window setVisible false” zamiast „main_window hide”, piszesz lub mówisz w ten sposób normalnie ?, po co używać tego dziwnego konstruowanie języka w programach, gdy jest to całkowicie możliwe, użyj bardziej naturalnego języka ?.

Wierzę, że im bardziej metoda jest ekspresyjna, tym bardziej czytelny, a tym samym łatwiejszy do utrzymania kod będzie. Rozważ następujące dwa przypadki:

Przypadek 1:

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

Przypadek 2:

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

W pierwszym przypadku jasne jest, co robi funkcja „setVisible”, ale jeśli chcesz ją przeczytać, powiedziałbyś:

ustaw panel klienta na widoczny, jeśli klient jest włączony lub ustaw go na ukryty, jeśli klient jest wyłączony.

Chociaż jest bardziej opisowy, aby powiedzieć:

• sprawdź status klienta:
  • jeśli klient jest włączony, pokaż panel klienta
  • w przeciwnym razie ukryj to

co spowoduje zmianę funkcji „Przypadek 1” na:

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

produkuje więcej kodu, ale jest bardziej czytelny.

Drugi przypadek ma oczywistą wadę, tzn. Już wiesz, że chcesz pokazać panel, więc dlaczego nie skorzystać z funkcji „Pokaż”?

Nie twierdzę, że użycie „setVisible” jest całkowicie błędne, ale staje się mylące, gdy próbujesz odczytać kod, który nie został napisany przez Ciebie z czasem, i nie jest zgodny z regułą „A funkcja powinna wykonać tylko jedną operację”.

Uważam, że alternatywa Hide()/ Show()jest atrakcyjna, ponieważ łatwiej jest zrozumieć, co się dzieje, niż przy SetVisible(true)jednoczesnym korzystaniu z jednej funkcji, ponieważ pozwala uniknąć wielu warunków warunkowych.

Jeśli o to chodzi to proponuję stosując wyliczenie jako wkładu SetVisible, więc masz albo SetVisible(Visibility.Visible)albo SetVisible(Visibility.Hidden). Masz jedną funkcję, dzięki której możesz natychmiast odczytać, jakie działania są podejmowane.

Używając konwencji nazewnictwa Java, możesz mieć setVisible(Visibility.VISIBLE)lub setVisible(Visibility.HIDDEN).

Zgadzam się z odpowiedzią Dariena, ale chciałem dodać punkt widzenia z perspektywy programistów C #.

Kiedy widzę kod z napisem „setXXX”, czytam to, aby ustawić wartość dla rzeczy, nie oczekuję, że będzie to miało skutki uboczne w tej rzeczy innej niż ustawienie tej wartości, i spodziewam się, że będzie to idempotentne (tzn. mogę nadal ustawiać tę samą wartość i jest w porządku). To raczej jak dostęp do pola. Generalnie spodziewałbym się również zobaczyć metodę „getXXX” wraz z „setXXX”.

Nie wiem, czy tego się spodziewasz w Javie i C ++, ale tego oczekiwałbym w C #, choć w C # jest krótka ręka dla tego o nazwie Właściwości. A oto kilka dobrych wskazówek na temat korzystania z właściwości ( http://msdn.microsoft.com/en-us/library/ms182181.aspx ).

Biorąc pod uwagę ten widok, wybór interfejsu zależy wyłącznie od tego, czy występują jakieś skutki uboczne (inne niż zmiana tej wartości pola):

Jeśli wykonanie akcji ma skutki uboczne, na przykład pokazuje okno dialogowe, wybrałbym „Show ()” i „Hide ()”.

Jeśli nie ma efektów ubocznych, powiedzmy, że ustawiam widoczność „widżetu”, a coś innego renderuje ten widżet w zależności od jego stanu, wtedy użyłbym setVisibility lub setIsVisible. (Nie nazwałbym tego SetVisible).

W języku C # (nie jestem pewien co do Javy) dość często przyjmuje się wzorzec obserwatora, w którym struktura interfejsu użytkownika będzie nasłuchiwać zmian w obiektach i automatycznie ponownie renderuje interfejs użytkownika, gdy zmieni się właściwość, taka jak Widoczność. Oznacza to, że ustawienie wartości przez wywołanie setIsVisible wygląda tak, jakby miało skutki uboczne, ale w mojej definicji tak nie jest. Kontrakt widżetu jest wypełniany poprzez ustawienie jego wartości pola reprezentującej „IsVisible”.

Innymi słowy, w porządku jest dla mnie przełączanie widoczności etykiety na formularzu przed wyświetleniem formularza. Tj. Label.getIsVisible == true, ale formularz nie jest wyświetlany.

Wywoływanie Hide () nie jest w porządku, gdy formularz nie jest wyświetlany.

Sugeruję nieco zmodyfikowany interfejs:

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

Lepsze imiona

Te nazwy metod pomagają programistom zdecydować, której metody użyć, w zależności od tego, co należy zrobić. Natomiast SetVisible(bool visible)mogą mylić dewelopera, ponieważ przekazuje tę samą semantyczne znaczenie, jak Show()i Hide(), Toggle()zakłada istnienie warunku, który określa działania. W ten sposób staje się intuicyjne dla programisty, kiedy należy użyć każdej metody.

Zredukowana redundancja kodu

Zaletą posiadania wielu metod w interfejsie jest to, że upraszcza kod wywołujący. Możesz po prostu ujawnić Show()i Hide(), ale:

• Prawdopodobnie potrzebujesz jakiejś SetVisible()prywatnej metody, aby wykonać prawdziwą pracę za kulisami (lub napisać zbędny kod dla Show()i Hide()).
• Kod wywołujący może mieć wiele zbędnych bloków if / else tylko po to, aby wybrać metodę, której należy użyć. Moim zdaniem powoduje to rozdęcie kodu.
• Gdybym był konsumentem, prawdopodobnie po prostu napisałbym własną funkcję opakowania, która robi to, co SetVisible()(lub Toggle()) już robi, aby uniknąć rozdęcia kodu (nienawidzę zbędnego kodu). W ten sposób powiela się metodę, która prawdopodobnie już istnieje jako metoda prywatna w implementacji.

Sugerowałbym użycie, SetVisible(bool)jeśli w ogóle, tylko jeśli dwukrotne przełączenie widoczności (pokaż i ponownie ukryj lub ukryj i ponownie pokaż) pozostawiłoby rzeczy w zasadniczo takim samym stanie, jak przed wykonaniem operacji (w porządku, jeśli pokazywanie i ukrywanie coś lub vice versa pozostawia obiekty wymagające przerysowania, pod warunkiem, że można oczekiwać, że nastąpi to „automatycznie”). Jeśli ukrywanie i pokazywanie obiektu nie przyniesie żadnego innego efektu niż zmiana jednego bitu stanu, wówczas sensownym byłoby, aby kod zewnętrzny miał pewne metody, które akceptują parametr widoczności, a pisanie takiego kodu będzie ułatwione SetVisible.

Jeśli ukrywanie i ponowne pokazywanie obiektu może mieć skutki uboczne, takie jak zmiana kolejności Z, takie działania powinny być częściej wykonywane osobnymi metodami. W takich przypadkach przydatność metod zewnętrznych, które akceptują parametr „widoczności”, będzie ograniczona, a zatem ułatwienie ich będzie niewielkie. Co więcej, SetVisiblemetoda (błędnie) zasugeruje, że zmiany widoczności obiektów można osiągnąć bez skutków ubocznych.