Dlaczego Java ma metody „void”?

Czy / dlaczego Java musi mieć voidmetody? Odniesienie :

Żadna metoda zadeklarowana jako nieważna nie zwraca wartości.

O ile myślę, każde użycie voidbyłoby lepiej obsługiwane przez zwrócenie flagi statusu, wywołanego obiektu lub null.

To sprawiłoby, że każde wywołanie byłoby stwierdzeniem, które można przypisać, i ułatwiłoby budowanie wzorców i tworzenie łańcuchów metod. Metody wywoływane tylko dla ich efektów zwykle zwracają wartość logiczną lub Successtyp ogólny lub zgłaszają wyjątek w przypadku niepowodzenia.

Ponieważ istnieje różnica między „Ta funkcja może odnieść sukces lub zawieść i jest na tyle świadoma, że ​​może odróżnić” i „Nie ma informacji zwrotnej na temat działania tej funkcji”. Bez voidtego bez końca sprawdzasz kody sukcesu i wierzysz, że piszesz solidne oprogramowanie, podczas gdy w rzeczywistości nie robisz nic takiego.

1. Ponieważ C ma voidtyp, a Java została zaprojektowana zgodnie z wieloma konwencjami rodziny języków C.
2. Istnieje wiele funkcji, których nie chcesz, aby zwracały wartość. Co w ogóle zrobisz z „ Successtypem ogólnym ”? W rzeczywistości zwracane wartości wskazujące na sukces są nawet mniej ważne w Javie niż w C, ponieważ Java ma wyjątki wskazujące na niepowodzenie, a C nie.

Oryginalny powód, dla którego język ma voidtyp jest bo jak w C, twórcy języka nie chce niepotrzebnie komplikować składnię języka z procedury s oraz funkcja ów drodze Pascal zrobił.

To był pierwotny powód.

Twoje sugestie:

zwracanie flagi stanu

To nie-nie. Nie używamy flag stanu. Jeśli coś pójdzie nie tak, zgłaszamy to w drodze wyjątków.

obiekt jest wywoływany

Płynny styl wywoływania jest najnowszym osiągnięciem. Wielu programistów, którzy dzisiaj bardzo chętnie posługują się biegle i przewracają oczami, jeśli kiedykolwiek będą musieli użyć interfejsu, który go nie obsługuje, nie powstało nawet podczas tworzenia Java.

zwracanie wartości null

Zmusiłoby cię to do zadeklarowania metody jako zwracania czegoś, podczas gdy w rzeczywistości nic nie zwraca, więc byłoby to bardzo mylące dla kogoś, kto patrzy na interfejs próbujący dowiedzieć się, co on robi. Ludzie nieuchronnie wymyśliliby jakąś bezużyteczną klasę oznaczającą „brak wartości zwracanej”, aby wszystkie funkcje, które nie mają nic do zwrócenia, mogły zwrócić zerowe odwołanie do takiej klasy. To byłoby niezgrabne. Na szczęście istnieje na to rozwiązanie, nazywa się to void. I to jest odpowiedź na twoje pytanie.

Niektóre metody, takie jak System.out.println, nie zwracają niczego użytecznego, ale są nazywane wyłącznie dla tego efektu ubocznego. voidjest pomocnym wskaźnikiem dla kompilatora i czytnika kodu, że żadna użyteczna wartość nie jest zwracana.

Zwrot nullzamiast voidoznacza, że ​​po prostu NullPointerExceptionużyjesz tej wartości do czegokolwiek. Wymieniasz więc błąd czasu kompilacji na błąd czasu wykonywania, który jest znacznie gorszy. Ponadto należy zdefiniować typ zwrotu jako Object, co byłoby mylące i mylące. (A łańcuchowanie nadal nie działałoby.)

Kody stanu są zwykle używane do wskazania warunków błędu, ale Java ma wyjątki w tym celu.

Zwrot thisnie jest możliwy z metod statycznych.

Zwrócenie ogólnego Successobiektu nie miałoby pożytecznego celu.

Jednym z powodów jest to, że zwrócenie czegoś innego niż, powiedzmy, może być mylącenull . Przykład:

Co powinieneś Arrays.sort(a)zwrócić?

Jeśli argumentujesz, że anależy zwrócić, aby połączenie mogło zostać powiązane (co wydaje się być twoją odpowiedzią na podstawie twojego pytania), to nie jest już jasne, czy zwracana wartość jest kopią oryginalnego obiektu, czy też samego obiektu oryginalnego . Oba są możliwe. I tak, możesz umieścić to w dokumentacji, ale jest to na tyle dwuznaczne, że nie powinieneś tworzyć dwuznaczności.

Z drugiej strony, jeśli argumentujesz, że nullpowinien zostać zwrócony, nasuwa się pytanie o to, jakie informacje potencjalnie zwraca wartość zwracająca i dlaczego programista powinien być zmuszony do pisania, return nullgdy nie przekazuje żadnych informacji.

A jeśli coś innego całkowicie absurdalne (jak długość powrócić a) to właśnie sprawia, że za pomocą tej wartości zwracanej naprawdę skomplikowane - wystarczy pomyśleć o ileż bardziej skomplikowane to znaczy int len = Arrays.sort(a)zamiast int len = A.length!

Zwracanie wartości, booleanktóra jest zawsze równa, truektórą sugerujesz, jest nie tylko bezcelowe (wartość zwracana nie zawiera żadnych informacji), ale w rzeczywistości byłaby myląca. Przez większość czasu, to najlepiej używać typów powrotne, które wykonują tylko tyle informacji, ile jest faktycznie dostępny - dlatego w Javie masz booleanna true/ falsezamiast Zwracanie intz 4 miliardów możliwych wartości. Podobnie zwrócenie a booleanz dwiema możliwymi wartościami, w przypadku których istnieje tylko jedna możliwa wartość („ogólny sukces”), byłoby mylące.

Zwiększyłoby to również niepotrzebny narzut wydajności.

Jeśli metoda jest używana tylko ze względu na efekt uboczny, nie ma nic do zwrócenia, a typ zwrotu voiddokładnie to odzwierciedla. Potencjalne rzadkie błędy mogą być sygnalizowane za pomocą wyjątków.

Jedną rzeczą, którą można ulepszyć, byłoby stworzenie voidrzeczywistego typu, takiego jak Scala Unit. Rozwiązałoby to niektóre problemy, takie jak obsługa leków generycznych.

Java jest stosunkowo starym językiem. A w 1995 r. (Kiedy został utworzony), a wkrótce potem programiści byli bardzo zaniepokojeni ilością czasu, jaką proces przejął kontrolę nad procesorem, a także zużyciem pamięci. Zwrócenie void wyeliminowałoby kilka cykli zegara i trochę zużycia pamięci z wywołania funkcji, ponieważ nie musiałbyś umieszczać wartości zwracanej na stosie, a następnie nie musiałbyś jej usuwać.

Efektywny kod nie daje ci czegoś, czego nigdy nie używałbyś, a zatem unieważnienie czegoś, co ma bezwartościową wartość zwrotną, jest znacznie lepszą praktyką niż zwracanie wartości sukcesu.

Przeczytałem argumenty sugerujące, że drugą opcją (return this) powinno być podejście zamiast void. Jest to całkiem dobry pomysł, ale podejście w stylu konstruktora nie było popularne w czasie tworzenia Java. Gdyby w tym czasie był tak popularny, jak teraz, mogłoby to być przyjęte podejście. Powrót nullto naprawdę zły pomysł IMO. Chciałbym, żeby nullw ogóle nie było tego języka.

Problem polega na tym, że jeśli metoda zwraca instancję własnego typu, nie jest jasne, czy jest to nowy obiekt, czy ten sam. Często nie ma (lub nie powinien) mieć znaczenia, ale innym razem ma to znaczenie. Podejrzewam, że język mógłby zostać zmieniony, aby domyślnie powrócić thisdo nieważnych metod. Jedyną kwestią, o której mogę teraz pomyśleć, jest to, że jeśli później metoda zostanie zmieniona w celu zwrócenia nowego obiektu tego samego typu, nie pojawią się żadne ostrzeżenia dotyczące kompilacji, ale może to nie jest wielka sprawa. Obecny system typów nie przejmuje się teraz tego rodzaju zmianami. Sposób interakcji z dziedziczeniem / interfejsami wymagałby pewnych rozważań, ale pozwoliłby na łatwe wywoływanie starych interfejsów API bez stylu konstruktora, tak jakby to zrobiły.

Kolejny aspekt:

Java to język statyczny z dość ścisłymi funkcjami. Oznacza to, że wiele rzeczy, które byłyby dość otwarte lub dynamiczne w innych językach (c / f Ruby, Lisp itp.) Są ściśle określone.

Jest to ogólna decyzja projektowa. Na „dlaczego” trudno jest odpowiedzieć (cóż, ponieważ projektanci języka sądzili, że będzie dobrze!). „Po co” jest dość jasne: pozwala kompilatorowi wykryć wiele błędów, co ogólnie jest całkiem dobrą cechą dla każdego języka. Po drugie, sprawia, że ​​stosunkowo łatwo jest zrozumieć język. Na przykład stosunkowo łatwo jest stworzyć formalne dowody poprawności w (podzestawach) języka Java; dla porównania byłoby to praktycznie niemożliwe w dynamicznym języku, takim jak Ruby i in.

Takie myślenie przenika język, na przykład wymuszoną deklarację możliwych wyjątków, które może rzucić metoda, osobny typ interfacekontra, classaby uniknąć niejednoznacznego wielokrotnego dziedziczenia i tak dalej. W rzeczywistości (statyczny imperialny język OOP w świecie rzeczywistym z silnym naciskiem na obsługę błędów w czasie kompilacji) te rzeczy są naprawdę dość eleganckie i potężne. Zbliżają się do języków teoretycznych (naukowych), które zostały celowo stworzone wyłącznie po to, aby zbadać niektóre z tych zagadnień niż jakikolwiek inny język rzeczywisty wcześniej (w tym czasie, pamiętajcie).

Więc. Posiadanie ścisłego voidtypu jest wyraźnym komunikatem: ta metoda niczego nie zwraca, kropka. Jest jak jest. Zastąpienie go wymuszeniem, aby zawsze zwracało coś, prowadziłoby do znacznie bardziej dynamicznego zachowania (tak jak w Ruby, gdzie każdy def ma zawsze wyraźną lub dorozumianą wartość zwrotu), co byłoby niekorzystne z punktu widzenia sprawdzalności i uzasadnienia; lub do masywnego wzdęcia za pomocą innego mechanizmu tutaj.

(I na przykład, Ruby (na przykład) radzi sobie z tym inaczej, a jego rozwiązanie jest nadal tak samo akceptowalne jak Java, ponieważ ma zupełnie inną filozofię. Na przykład wyrzuca możliwości sprawdzania się i rozsądności całkowicie poza okno, kładąc duży nacisk na wyjątkowo wysoka ekspresja języka).