Jak mogę nawiązać połączenie z logicznym rozwiązaniem? Boolean Trap

Jak zauważono w komentarzach @ benjamin-gruenbaum, nazywa się to pułapką logiczną:

Powiedz, że mam taką funkcję

UpdateRow(var item, bool externalCall);

a w moim kontrolerze ta wartość externalCallzawsze będzie PRAWDA. Jak najlepiej wywołać tę funkcję? Zwykle piszę

UpdateRow(item, true);

Ale pytam samego siebie, czy powinienem zadeklarować wartość logiczną, aby wskazać, co oznacza ta „prawdziwa” wartość? Możesz to wiedzieć, patrząc na deklarację funkcji, ale jest to oczywiście szybsze i wyraźniejsze, jeśli zobaczysz coś takiego

bool externalCall = true;
UpdateRow(item, externalCall);

PD: Nie jestem pewien, czy to pytanie naprawdę pasuje tutaj, jeśli nie, gdzie mogę uzyskać więcej informacji na ten temat?

PD2: Nie oznaczyłem żadnego języka, ponieważ myślałem, że to bardzo ogólny problem. W każdym razie pracuję z c # i zaakceptowana odpowiedź działa dla c #

Nie zawsze jest idealne rozwiązanie, ale masz wiele alternatyw do wyboru:

• Użyj nazwanych argumentów , jeśli są dostępne w Twoim języku. Działa to bardzo dobrze i nie ma szczególnych wad. W niektórych językach dowolny argument można przekazać jako nazwany argument, np. updateRow(item, externalCall: true)( C # ) lub update_row(item, external_call=True)(Python).

  Twoja sugestia użycia oddzielnej zmiennej jest jednym ze sposobów symulacji nazwanych argumentów, ale nie ma związanych z tym korzyści bezpieczeństwa (nie ma gwarancji, że użyłeś poprawnej nazwy zmiennej dla tego argumentu).

• Używaj różnych funkcji dla swojego publicznego interfejsu, z lepszymi nazwami. Jest to inny sposób symulowania nazwanych parametrów poprzez umieszczenie w nazwie wartości parametrów paremeter.

  Jest to bardzo czytelne, ale prowadzi do wielu pytań dla Ciebie, który pisze te funkcje. Nie może również dobrze poradzić sobie z eksplozją kombinatoryczną, gdy istnieje wiele argumentów boolowskich. Istotną wadą jest to, że klienci nie mogą ustawić tej wartości dynamicznie, ale muszą użyć if / else, aby wywołać poprawną funkcję.

• Użyj wyliczenia . Problem z booleanami polega na tym, że nazywane są „prawdą” i „fałszem”. Zamiast tego wprowadź typ o lepszych nazwach (np enum CallType { INTERNAL, EXTERNAL }.). Dodatkową korzyścią jest zwiększenie bezpieczeństwa typów programu (jeśli Twój język implementuje wyliczenia jako odrębne typy). Wadą wyliczeń jest to, że dodają typ do publicznie widocznego interfejsu API. W przypadku funkcji czysto wewnętrznych nie ma to znaczenia, a wyliczenia nie mają znaczących wad.

  W językach bez wyliczeń czasami używane są krótkie ciągi znaków . Działa to, a może nawet lepiej niż surowe booleany, ale jest bardzo podatne na literówki. Funkcja powinna następnie natychmiast stwierdzić, że argument pasuje do zestawu możliwych wartości.

Żadne z tych rozwiązań nie ma nadmiernego wpływu na wydajność. Nazwane parametry i wyliczenia można całkowicie rozwiązać w czasie kompilacji (dla skompilowanego języka). Korzystanie z ciągów znaków może wiązać się z porównywaniem ciągów, ale ich koszt jest znikomy w przypadku małych literałów ciągów i większości rodzajów aplikacji.

Prawidłowym rozwiązaniem jest robienie tego, co sugerujesz, ale zapakuj je w minifasadę:

void updateRowExternally() {
  bool externalCall = true;
  UpdateRow(item, externalCall);
}

Czytelność przebija mikrooptymalizację. Możesz sobie pozwolić na dodatkowe wywołanie funkcji, na pewno lepiej niż na wysiłek programisty polegający na konieczności sprawdzenia semantyki flagi logicznej nawet raz.

Powiedzmy, że mam taką funkcję jak UpdateRow (var item, bool externalCall);

Dlaczego masz taką funkcję?

W jakich okolicznościach wywołałbyś to z argumentem externalCall ustawionym na inne wartości?

Jeśli jedna pochodzi, powiedzmy, z zewnętrznej aplikacji klienckiej, a druga znajduje się w tym samym programie (tj. Różnych modułach kodu), to argumentowałbym, że powinieneś mieć dwie różne metody, jedną dla każdego przypadku, być może nawet zdefiniowaną odrębnie Interfejsy

Jeśli jednak wykonujesz wywołanie na podstawie pewnej bazy danych pobranej ze źródła innego niż program (powiedzmy, plik konfiguracyjny lub odczyt bazy danych), wówczas metoda przekazywania wartości logicznej byłaby bardziej sensowna.

Chociaż zgadzam się, że idealnym rozwiązaniem jest użycie funkcji językowej w celu wymuszenia zarówno czytelności, jak i bezpieczeństwa wartości, możesz również zdecydować się na praktyczne podejście: komentarze w czasie rozmowy. Lubić:

UpdateRow(item, true /* row is an external call */);

lub:

UpdateRow(item, true); // true means call is external

lub (słusznie, jak sugeruje Frax):

UpdateRow(item, /* externalCall */true);

1. Możesz „nazwać” swoje boole. Poniżej znajduje się przykład języka OO (gdzie można go wyrazić w klasie zapewniającej UpdateRow()), jednak samą koncepcję można zastosować w dowolnym języku:

   class Table
   {
   public:
       static const bool WithExternalCall = true;
       static const bool WithoutExternalCall = false;
   

   i na stronie połączenia:

   UpdateRow(item, Table::WithExternalCall);
   

2. Uważam, że pozycja nr 1 jest lepsza, ale nie zmusza użytkownika do korzystania z nowych zmiennych podczas korzystania z funkcji. Jeśli bezpieczeństwo typu jest dla Ciebie ważne, możesz utworzyć enumtyp i UpdateRow()zaakceptować to zamiast bool:

   UpdateRow(var item, ExternalCallAvailability ec);

3. Możesz zmodyfikować nazwę funkcji, aby lepiej odzwierciedlała znaczenie boolparametru. Nie jestem pewien, ale może:

   UpdateRowWithExternalCall(var item, bool externalCall)

Inną opcją, której jeszcze tu nie czytałem, jest: Użyj nowoczesnego IDE.

Na przykład IntelliJ IDEA drukuje nazwę zmiennej w metodzie, którą wywołujesz, jeśli przekazujesz literał taki jak truelub nulllub username + “@company.com. Odbywa się to małą czcionką, dzięki czemu nie zajmuje dużo miejsca na ekranie i wygląda bardzo różnie od rzeczywistego kodu.

Nadal nie twierdzę, że dobrym pomysłem jest wrzucanie boolczyków wszędzie. Argument mówiący, że czytasz kod znacznie częściej niż piszesz, jest często bardzo silny, ale w tym konkretnym przypadku w dużej mierze zależy on od technologii, której używasz (i twoi koledzy!) Do wspierania twojej pracy. Z IDE jest to o wiele mniejszy problem niż na przykład z vimem.

Zmodyfikowany przykład części mojej konfiguracji testowej:

2 dni i nikt nie wspomniał o polimorfizmie?

target.UpdateRow(item);

Kiedy jestem klientem, który chce zaktualizować wiersz o element, nie chcę myśleć o nazwie bazy danych, adresie URL mikro-usługi, protokole używanym do komunikacji ani o tym, czy połączenie zewnętrzne jest trzeba będzie użyć, aby tak się stało. Przestańcie narzucać mi te szczegóły. Po prostu weź mój przedmiot i idź już gdzieś zaktualizować wiersz.

Zrób to, a stanie się to częścią problemu konstrukcyjnego. Można to rozwiązać na wiele sposobów. Tu jest jeden:

Target xyzTargetFactory(TargetBuilder targetBuilder) {
    return targetBuilder
        .connectionString("some connection string")
        .table("table_name")
        .external()
        .build()
    ; 
}

Jeśli patrzysz na to i myślisz „Ale mój język wymienia argumenty, nie potrzebuję tego”. Dobrze, świetnie, idź ich użyć. Po prostu trzymaj ten nonsens z dala od dzwoniącego klienta, który nie powinien nawet wiedzieć, z czym rozmawia.

Należy zauważyć, że jest to więcej niż problem semantyczny. To także problem projektowy. Podaj wartość logiczną, a będziesz musiał użyć rozgałęzienia, aby sobie z tym poradzić. Niezbyt zorientowany obiektowo. Masz dwa lub więcej booleanów do przejścia? Czy chcesz, aby Twój język miał wiele wysyłek? Sprawdź, co mogą zrobić kolekcje po ich zagnieżdżeniu. Odpowiednia struktura danych może znacznie ułatwić Ci życie.

Jeśli możesz zmodyfikować updateRowfunkcję, być może uda ci się przekształcić ją w dwie funkcje. Biorąc pod uwagę, że funkcja przyjmuje parametr boolowski, podejrzewam, że wygląda to tak:

function updateRow(var item, bool externalCall) {
  Database.update(item);

  if (externalCall) {
    Service.call();
  }
}

To może być trochę zapachowy kod. Funkcja może mieć zupełnie inne zachowanie w zależności od ustawienia externalCallzmiennej, w którym to przypadku ma dwie różne obowiązki. Przekształcenie go w dwie funkcje, które mają tylko jedną odpowiedzialność, może poprawić czytelność:

function updateRowAndService(var item) {
  updateRow(item);
  Service.call();
}

function updateRow(var item) {
  Database.update(item);
}

Teraz, gdziekolwiek wywołasz te funkcje, możesz od razu stwierdzić, czy wywoływana jest usługa zewnętrzna.

Oczywiście nie zawsze tak jest. Jest to sytuacja i kwestia gustu. Przeformułowanie funkcji, która przyjmuje parametr logiczny na dwie funkcje, jest zwykle warte rozważenia, ale nie zawsze jest najlepszym wyborem.

Jeśli UpdateRow znajduje się w kontrolowanej bazie kodu, rozważę wzorzec strategii:

public delegate void Request(string query);    
public void UpdateRow(Item item, Request request);

Gdzie Request reprezentuje pewnego rodzaju DAO (oddzwanianie w trywialnym przypadku).

Prawdziwy przypadek:

UpdateRow(item, query =>  queryDatabase(query) ); // perform remote call

Fałszywy przypadek:

UpdateRow(item, query => readLocalCache(query) ); // skip remote call

Zwykle implementacja punktu końcowego byłaby skonfigurowana na wyższym poziomie abstrakcji i po prostu użyłbym jej tutaj. Jako przydatny darmowy efekt uboczny daje mi możliwość zaimplementowania innego sposobu dostępu do danych zdalnych, bez żadnych zmian w kodzie:

UpdateRow(item, query => {
  var data = readLocalCache(query);
  if (data == null) {
    data = queryDatabase(query);
  }
  return data;
} );

Zasadniczo taka inwersja kontroli zapewnia niższe sprzężenie między przechowywaniem danych a modelem.