Чому у Java є `void` методи?

Чи / для чого Java потрібно мати voidметоди? Довідка :

Будь-який метод, оголошений недійсним, не повертає значення.

Наскільки я можу подумати, кожне використання voidбуло б краще обслуговуватися шляхом повернення прапора статусу, об'єкта, на який викликається, або null.

Це зробило б кожен виклик заявою, яка може бути присвоєною, та полегшила б шаблони розробників та ланцюжок методів. Методи, на які посилаються лише їх ефекти, як правило, повертають булевий або загальний Successтип або викидають виняток у разі відмови.

Тому що існує різниця між "Ця функція може успішно перемогти або вийти з ладу і є достатньо усвідомленою, що може сказати різницю" та "Немає відгуків про ефект цієї функції". Без цього voidви будете нескінченно перевіряти коди успіху і вважаєте, що ви пишете надійне програмне забезпечення, коли ви насправді нічого не робите.

1. Оскільки C має voidтип, а Java створена для дотримання багатьох конвенцій сімейства мов C.
2. Існує багато функцій, які не хочуть повертати значення. Що ви все одно будете робити з "родовим Successтипом"? Насправді повернені значення для вказівки на успіх є навіть менш важливими для Java, ніж для C, оскільки у Java є винятки, які свідчать про збій, а C - ні.

Оригінальна причина , чому мова має voidтип, тому що , як і в C, творці мови не хочуть зайве ускладнити синтаксис мови з процедурою з і функцією и шляхом Паскаль зробив.

Це була первісна причина.

Ваші пропозиції:

повернення прапора статусу

Це ні-ні. Ми не використовуємо прапори статусу. Якщо щось піде не так, ми повідомляємо про це через винятки.

об'єкт, на який викликається

Вільний стиль викликів - це нещодавній розвиток. Багато програмістів, які сьогодні дуже щасливо безперешкодно користуються та заплющують очі, якщо їм коли-небудь доведеться користуватися інтерфейсом, який не підтримує його, навіть не народилися під час створення Java.

повернення нуля

Це змусить вас оголосити метод як повернення чогось, коли насправді він нічого не повертає, тому було б дуже заплутаним той, хто дивиться на інтерфейс, намагаючись зрозуміти, що він робить. Люди неминуче вигадують якийсь інакше непридатний клас, який розшифровується як "не повертається значення", так що всі функції, які не мають нічого повернути, можуть повернути нульове посилання на такий клас. Це було б незграбно. На щастя, для цього є рішення, воно називається void. І це відповідь на ваше запитання.

Деякі методи, як-от System.out.println, не повертають нічого корисного, але називаються виключно для цього побічного ефекту. voidє корисним показником для компілятора і для читача коду, що корисне значення не повертається.

Повернувшись nullзамість voidзасобів, ви просто отримаєте NullPointerExceptionмить, коли використаєте це значення для чого-небудь. Таким чином, ви торгуєте помилкою компіляції за помилку виконання, що значно гірше. Крім того, вам доведеться визначити тип повернення як такий Object, що вводить в оману та заплутано. (І прикувати все одно не вийде.)

Коди статусу зазвичай використовуються для вказівки на умови помилок, але у Java для цього є винятки.

Повернення thisнеможливо статичними методами.

Повернення родового Successоб’єкта не мало б корисної мети.

Однією з причин є те , що він може бути в оману , щоб коли - небудь повернутися нічого іншого , ніж, скажімо, null. Приклад:

Що слід Arrays.sort(a)повернути?

Якщо ви стверджуєте, що його aслід повернути, щоб виклик був ланцюговим (що, здається, є вашою відповіддю, судячи з вашого запитання), то вже не зрозуміло, чи є повернене значення копією оригінального об'єкта, або самим оригінальним об'єктом . І те й інше можливо. Так, ви можете це помістити в документацію, але це досить неоднозначно, що не слід створювати неоднозначність в першу чергу.

З іншого боку, якщо ви стверджуєте, що його nullслід повернути, то виникає питання про те, яку інформацію повернення значення, можливо, забезпечує абонент, і чому програміст повинен змушений писати, return nullколи він не передає ніякої інформації.

І якщо ви повертаєте щось інше абсолютно абсурдне (як, наприклад, довжина a), то воно просто робить використання цього поверненого значення справді заплутаним - просто подумайте, як набагато заплутаніше сказати int len = Arrays.sort(a)замість цього int len = A.length!

Повернення, booleanяке завжди дорівнює тому, trueщо ви пропонуєте, не тільки безглуздо (повернене значення не містить інформації), але й насправді вводить в оману. Велику частину часу, то краще використовувати повертаються типи , які тільки несуть стільки інформації , скільки насправді доступні - ось чому в Java у вас є booleanдля true/ , falseа не повертаючи intз 4 мільярдів можливих значень. Так само, повернення а booleanз двома можливими значеннями, де існує лише одне можливе значення ("загальний успіх"), було б оманливим.

Це також додасть непотрібних накладних витрат.

Якщо метод використовується лише для його побічного ефекту, повернути нічого немає, а тип повернення voidвідображає саме це. Про можливі рідкісні помилки можна сигналізувати за винятком.

Одне, що можна було б вдосконалити, - це створення voidфактичного типу, наприклад, Scala Unit. Це дозволить вирішити деякі проблеми, такі як обробка дженериків.

Java - відносно стара мова. А в 1995 році (коли він був створений) і незабаром після цього програмісти були дуже стурбовані тим, скільки часу процес взяв контроль над процесором, а також витратою пам'яті. Повернення порожнечі призвело до усунення декількох тактових циклів та трохи споживання пам'яті з виклику функції, оскільки вам не доведеться ставити значення повернення на стек, і згодом вам не доведеться його видаляти.

Ефективний код не повертає вам те, що ви ніколи не використовуватимете, а значить, пустота в щось, що має безглузде значення повернення, є набагато кращою практикою, ніж повернення значення успіху.

Я читав аргументи, які підказують, що другим варіантом (поверненням this) повинен бути підхід замість void. Це досить гарна ідея, але підхід у стилі будівельника не був популярним у той час, коли створювалася Java. Якби вона була настільки популярною в той час, як зараз, це, можливо, був би такий підхід. Повернення null- це дуже погана ідея ІМО. Мені б хотілося, щоб nullнавіть не було мови.

Проблема зараз полягає в тому, що якщо метод повертає екземпляр власного типу, не ясно, чи це новий об'єкт, чи той самий. Часто це не має значення (або не повинно) мати значення, але в інших випадках це має значення. Я припускаю, що мову можна змінити, щоб неявно повернутись thisдо недійсних методів. Єдине питання, про яке я можу з цим вирішити наразі, це те, що якби метод згодом був змінений, щоб повернути новий об'єкт того ж типу, не було б жодних попереджень щодо компіляції, але це, можливо, не велика справа. Поточна система типів зараз не переймається тими змінами. Те, як це взаємодіє із спадковими / інтерфейсами, потребує певного розгляду, але це дозволить старим API без стилю конструктора легко викликати, як ніби вони.

Ще один аспект:

Java - статична мова з досить суворими можливостями. Це означає, що багато речей, які були б цілком відкритими або динамічними іншими мовами (c / f Ruby, Lisp тощо), суворо визначені.

Це загальне дизайнерське рішення. На "чому" важко відповісти (ну, адже дизайнери мови вважали, що це буде добре!). "Що для" досить зрозуміло: він дозволяє компілятору виявити безліч помилок, що, як правило, є досить хорошою особливістю для будь-якої мови. По-друге, досить легко міркувати про мову. Наприклад, відносно легко створити формальну коректність, що підтверджується (підмножинами) мови Java; для порівняння, це було б практично неможливо в такій динамічній мові, як Ruby et al.

Це мислення пронизує мову, наприклад, вимушене заяву про можливі винятки , що метод може кинути, окремий тип interfaceVS. , classщоб уникнути неоднозначного множинного спадкоємства, і так далі. Оскільки це (статична імперативна мова реального світу OOP з сильним упором на обробку помилок у часі компіляції), ці речі насправді є досить елегантними та потужними. Вони наближаються до теоретичних (наукових) мов, які цілеспрямовано створені лише для того, щоб вивчити деякі з цих питань, ніж будь-яка інша мова в реальному світі (на той час, пам'ятайте).

Тому. Суворий voidтип - це чітке повідомлення: цей метод нічого не повертає, періоду. Це те, що воно є. Заміна цього примусу завжди повертати щось призведе до або набагато більш динамічної поведінки (як, наприклад, у Ruby, де кожен def завжди має явне або неявне повернення), що було б погано для доказів та міркувань; або до масового набряку, використовуючи тут якийсь інший механізм.

(І NB: Рубі (наприклад) вирішує це по-різному, і його рішення все ще настільки ж прийнятне, як і у Java, тому що має абсолютно іншу філософію. Наприклад, він викидає провісність і розумність повністю у вікно, роблячи велику увагу на надзвичайно висока виразність мови.)