Czy w moich metodach należy akceptować puste kolekcje, które się nad nimi powtarzają?

Mam metodę, w której cała logika jest wykonywana w pętli foreach, która iteruje nad parametrem metody:

public IEnumerable<TransformedNode> TransformNodes(IEnumerable<Node> nodes)
{
    foreach(var node in nodes)
    {
        // yadda yadda yadda
        yield return transformedNode;
    }
}

W takim przypadku wysłanie pustej kolekcji skutkuje pustą kolekcją, ale zastanawiam się, czy to nierozsądne.

Moja logika polega na tym, że jeśli ktoś wywołuje tę metodę, to zamierza przekazać dane i przekazałby pustą kolekcję mojej metodzie tylko w błędnych okolicznościach.

Czy powinienem wychwycić to zachowanie i zgłosić wyjątek, czy też najlepszą praktyką jest zwrócenie pustej kolekcji?

Metody użytkowe nie powinny rzucać pustych kolekcji. Twoi klienci API nienawidzą cię za to.

Kolekcja może być pusta; „kolekcja-która-nie może być pusta” jest koncepcyjnie znacznie trudniejsza do pracy.

Przekształcenie pustej kolekcji ma oczywisty skutek: pusta kolekcja. (Możesz nawet zaoszczędzić trochę śmieci, zwracając sam parametr.)

Istnieje wiele okoliczności, w których moduł przechowuje listy rzeczy, które mogą, ale nie muszą być już czymś wypełnione. Konieczność sprawdzania pustki przed każdym wezwaniem do transformjest denerwująca i może przekształcić prosty, elegancki algorytm w brzydki bałagan.

Metody użyteczności powinny zawsze dążyć do tego, aby ich wkład był liberalny, a wyniki - konserwatywne.

Z tych wszystkich powodów, na miłość boską, postępuj właściwie z pustą kolekcją. Nic nie jest bardziej irytujące niż moduł pomocnika, który myśli, że wie, czego chcesz lepiej niż ty.

Widzę dwa ważne pytania, które determinują odpowiedź na to:

1. Czy twoja funkcja może zwrócić coś sensownego i logicznego po przekazaniu pustej kolekcji (w tym null )?
2. Jaki jest ogólny styl programowania w tej aplikacji / bibliotece / zespole? (W szczególności, jak się masz FP?)

1. Znaczący zwrot

Zasadniczo, jeśli możesz zwrócić coś znaczącego, nie rzucaj wyjątku. Pozwól dzwoniącemu poradzić sobie z wynikiem. Więc jeśli twoja funkcja ...

• Liczy liczbę elementów w kolekcji, zwraca 0. To było łatwe.
• Wyszukuje elementy spełniające określone kryteria, zwraca pustą kolekcję. Proszę nic nie rzucać. Dzwoniący może mieć ogromną kolekcję kolekcji, z których niektóre są puste, a niektóre nie. Dzwoniący chce dowolnych pasujących elementów w dowolnej kolekcji. Wyjątki tylko utrudniają życie dzwoniącemu.
• Szuka największych / najmniejszych / najlepiej dopasowanych do kryteriów na liście. Ups W zależności od pytania o styl możesz tutaj rzucić wyjątek lub możesz zwrócić wartość null . Nienawidzę null (w dużej mierze osoby FP), ale jest to prawdopodobnie bardziej znaczące tutaj i pozwala zarezerwować wyjątki na nieoczekiwane błędy w twoim własnym kodzie. Jeśli dzwoniący nie sprawdzi wartości zerowej, i tak powstanie dość wyraźny wyjątek. Ale zostaw to im.
• Pyta o n-ty element w kolekcji lub o pierwszy / ostatni n elementów. Jest to najlepszy jak dotąd wyjątek i ten, który w najmniejszym stopniu może powodować zamieszanie i trudności dla dzwoniącego. Sprawa nadal może zostać złożona na wartość zerową, jeśli ty i twój zespół jesteście przyzwyczajeni do sprawdzania tego, ze wszystkich powodów podanych w poprzednim punkcie, ale jest to najbardziej uzasadniony jak dotąd przypadek zgłoszenia wyjątku DudeYou Know YouShouldCheckTheSizeFirst . Jeśli twój styl jest bardziej funkcjonalny, albo zeruj, albo czytaj dalej odpowiedź na mój styl .

Ogólnie rzecz biorąc, moje uprzedzenie do FP mówi mi „zwróć coś znaczącego”, a null może mieć w tym przypadku ważne znaczenie.

2. Styl

Czy Twój ogólny kod (lub kod projektu lub kod zespołu) faworyzuje styl funkcjonalny? Jeśli nie, należy spodziewać się wyjątków i zająć się nimi. Jeśli tak, rozważ zwrócenie typu opcji . W przypadku typu opcji zwracana jest znacząca odpowiedź lub Brak / Nic . W moim trzecim przykładzie z góry Nic nie byłoby dobrą odpowiedzią w stylu FP. Fakt, że funkcja zwraca typ opcji wyraźnie dzwoniącemu niż sensowna odpowiedź, może nie być możliwy i osoba dzwoniąca powinna być na to przygotowana. Wydaje mi się, że daje to dzwoniącemu więcej opcji (jeśli wybaczysz kalamburowi).

F # jest gdzie wszystkie fajne .Net dzieci robić tego typu rzeczy, ale C # ma wspierać ten styl.

tl; dr

Zachowaj wyjątki dla nieoczekiwanych błędów we własnej ścieżce kodu, nie do końca przewidywalnych (i legalnych) danych wejściowych pochodzących od kogoś innego.

Jak zawsze to zależy.

Czy to ważne, że kolekcja jest pusta?
Większość kodu obsługi kolekcji prawdopodobnie powiedziałaby „nie”; kolekcja może zawierać dowolną liczbę elementów, w tym zero.

Teraz, jeśli masz jakąś kolekcję, w której „nieważne” jest to, że nie ma w niej żadnych przedmiotów, jest to nowy wymóg i musisz zdecydować, co z tym zrobić.

Pożycz trochę logiki testowania ze świata bazy danych: test na zero przedmiotów, jeden przedmiot i dwa przedmioty. Dotyczy to najważniejszych przypadków (spłukanie źle sformułowanych wewnętrznych lub kartezjańskich warunków łączenia).

W ramach dobrego projektu zaakceptuj jak najwięcej zmian w danych wejściowych, tak praktycznych, jak to możliwe. Wyjątki powinny być zgłaszane tylko wtedy, gdy (niedopuszczalne dane wejściowe są prezentowane LUB wystąpią nieoczekiwane błędy podczas przetwarzania) ORAZ program nie może kontynuować w przewidywalny sposób .

W takim przypadku należy się spodziewać, że zostanie zaprezentowana pusta kolekcja, a Twój kod musi ją obsłużyć (co już robi). Byłoby naruszeniem wszystkiego, co dobre, gdyby Twój kod zgłosił tutaj wyjątek. Byłoby to podobne do mnożenia 0 przez 0 w matematyce. Jest zbędny, ale absolutnie niezbędny, aby działał tak, jak działa.

Teraz przejdźmy do argumentu zerowej kolekcji. W tym przypadku kolekcja zerowa jest błędem programistycznym: programista zapomniał przypisać zmienną. Jest to przypadek, w którym wyjątek może zostać zgłoszony, ponieważ nie można w sposób znaczący przetworzyć go w dane wyjściowe, a próba zrobienia tego spowodowałaby nieoczekiwane zachowanie. Byłoby to podobne do dzielenia przez zero w matematyce - jest to całkowicie bez znaczenia.

Właściwe rozwiązanie jest znacznie trudniejsze do zauważenia, gdy patrzysz tylko na swoją funkcję w izolacji. Rozważ swoją funkcję jako część większego problemu . Jedno z możliwych rozwiązań tego przykładu wygląda następująco (w Scali):

input.split("\\D")
.filterNot (_.isEmpty)
.map (_.toInt)
.filter (x => x >= 1000 && x <= 9999)

Najpierw dzielisz ciąg znaków na nie cyfrowy, odfiltrowujesz puste ciągi, konwertujesz ciągi na liczby całkowite, a następnie filtrujesz, aby zachować tylko liczby czterocyfrowe. Twoja funkcja może być map (_.toInt)w przygotowaniu.

Ten kod jest dość prosty, ponieważ każdy etap w potoku obsługuje tylko pusty ciąg lub pustą kolekcję. Jeśli umieścisz pusty ciąg na początku, otrzymasz pustą listę na końcu. Nie musisz się zatrzymywać i sprawdzać nullani wyjątku po każdym połączeniu.

Oczywiście, zakładając, że pusta lista wyników nie ma więcej niż jednego znaczenia. Jeśli musisz odróżnić puste wyjście spowodowane pustym wejściem od tego spowodowane przez samą transformację, to całkowicie to zmienia.

To pytanie dotyczy w rzeczywistości wyjątków. Jeśli spojrzysz na to w ten sposób i zignorujesz pustą kolekcję jako szczegół implementacji, odpowiedź jest prosta:

1) Metoda powinna zgłosić wyjątek, gdy nie może kontynuować: albo nie może wykonać wyznaczonego zadania, albo zwrócić odpowiednią wartość.

2) Metoda powinna wychwycić wyjątek, gdy jest w stanie kontynuować pomimo niepowodzenia.

Zatem twoja metoda pomocnicza nie powinna być „pomocna” i rzucać wyjątek, chyba że nie jest w stanie wykonać swojej pracy z pustą kolekcją. Pozwól dzwoniącemu ustalić, czy wyniki mogą być obsługiwane.

Niezależnie od tego, czy zwraca pustą kolekcję, czy ma wartość NULL, jest to nieco trudniejsze, ale niewiele: należy w miarę możliwości unikać kolekcji zerowalnych. Celem zbioru zerowalnego byłoby wskazanie (jak w SQL), że nie masz informacji - na przykład zbiór dzieci może być zerowy, jeśli nie wiesz, czy ktoś go posiada, ale nie masz wiedzą, że nie. Ale jeśli jest to ważne z jakiegoś powodu, prawdopodobnie warto go śledzić.

Nazwa metody TransformNodes. W przypadku pustej kolekcji jako danych wejściowych odzyskanie pustej kolekcji jest naturalne i intuicyjne i ma sens matematyczny.

Jeśli metoda została nazwana Maxi zaprojektowana tak, aby zwracała maksymalną liczbę elementów, naturalnym byłoby wrzucenie NoSuchElementExceptionpustej kolekcji, ponieważ maksimum niczego nie ma sensu matematycznego.

Jeśli metoda została nazwana JoinSqlColumnNamesi zaprojektowana w taki sposób, aby zwracała ciąg znaków, do którego elementy są połączone przecinkiem w celu użycia w zapytaniach SQL, wówczas sensownym byłoby wrzucenie IllegalArgumentExceptionpustej kolekcji, ponieważ wywołujący i tak otrzymałby błąd SQL, gdyby użył ciąg w zapytaniu SQL bezpośrednio bez dalszych sprawdzeń, a zamiast sprawdzania zwróconego pustego ciągu naprawdę powinien był sprawdzić, czy nie ma pustej kolekcji.

Cofnijmy się i skorzystajmy z innego przykładu, który oblicza średnią arytmetyczną tablicy wartości.

Jeśli tablica wejściowa jest pusta (lub zerowa), czy możesz w uzasadniony sposób spełnić żądanie osoby dzwoniącej? Nie. Jakie masz opcje? Cóż, możesz:

• przedstawić / zwrócić / wyrzucić błąd. używając konwencji bazy kodu dla tej klasy błędów.
• dokument, że zostanie zwrócona wartość taka jak zero
• dokument, że wyznaczona niepoprawna wartość zostanie zwrócona (np. NaN)
• dokument, że zostanie zwrócona magiczna wartość (np. min. lub maks. dla danego typu lub jakaś wartość, która może być wskazująca)
• ogłosić, że wynik nie jest określony
• zadeklaruj, że akcja jest niezdefiniowana
• itp.

Mówię, że daj im błąd, jeśli podali ci nieprawidłowe dane wejściowe, a prośba nie może zostać zrealizowana. Mam na myśli poważny błąd od pierwszego dnia, aby zrozumieli wymagania twojego programu. W końcu twoja funkcja nie jest w stanie odpowiedzieć. Jeśli operacja może się nie powieść (np. Skopiować plik), wówczas Twój interfejs API powinien dać im błąd, z którym mogą sobie poradzić.

Dzięki temu można zdefiniować sposób obsługi źle sformułowanych żądań i żądań, które mogą się nie powieść.

Bardzo ważne jest, aby kod był spójny w zakresie obsługi tych klas błędów.

Kolejną kategorią jest decyzja, w jaki sposób Twoja biblioteka będzie obsługiwać nonsensowne żądania. Wracając do przykładu podobny do Ciebie - użyjmy funkcję, która określa, czy plik istnieje w ścieżce: bool FileExistsAtPath(String). Jeśli klient przekaże pusty ciąg, jak poradzić sobie z tym scenariuszem? Co powiesz na pustą lub zerową tablicę przekazaną void SaveDocuments(Array<Document>)? Wybierz bibliotekę / bazę kodów i zachowaj spójność. Zdarza mi się brać pod uwagę te przypadki błędów i zabraniam klientom wysuwania bzdurnych żądań, oznaczając je jako błędy (poprzez asercję). Niektórzy ludzie zdecydowanie oprą się temu pomysłowi / działaniu. Uważam, że to wykrywanie błędów jest bardzo pomocne. Jest bardzo dobry do lokalizowania problemów w programach - z dobrą lokalizacją dla szkodliwego programu. Programy są znacznie bardziej przejrzyste i poprawne (rozważ ewolucję bazy kodu) i nie nagrywaj cykli w ramach funkcji, które nic nie robią. Kod jest mniejszy / czystszy w ten sposób, a kontrole są generalnie wypychane do miejsc, w których problem może zostać wprowadzony.

Zasadniczo standardowa funkcja powinna być w stanie zaakceptować jak najszerszą listę danych wejściowych i przekazać informacje zwrotne na jej temat, istnieje wiele przykładów, w których programiści używają funkcji w sposób, który nie został zaplanowany przez projektanta, dlatego też uważam, że funkcja powinien być w stanie zaakceptować nie tylko puste kolekcje, ale szeroki zakres typów danych wejściowych i wdzięcznie zwracać informacje zwrotne, czy to nawet obiekt błędu z jakiejkolwiek operacji wykonanej na wejściu ...