The following text is a partial translation of the original English article, performed by ChatGPT (gpt-3.5-turbo) and this Jekyll plugin:
Я наткнулся на этот предложение от Брайана Гоэтца о классах данных в Java и сразу осознал, что у меня тоже есть несколько идей о том, как сделать Java лучше в качестве языка. У меня есть много идей, но вот краткий список из пяти самых важных.
Глобальные переменные. В Java есть Одиночки, которые, как мы все знаем, являются ничем иным, как глобальными переменными. Не было бы замечательно включить глобальные переменные в Java и избавиться от Одиночек. PHP, JavaScript, Ruby и многие другие языки имеют их, почему Java нет? Посмотрите на этот код:
Затем, чтобы получить к нему доступ, нам нужно использовать:
Это Singleton. Видите, насколько многословен он? Мы можем просто заменить его глобальной переменной (я предлагаю использовать ключевое слово global).
And then:
user.getName();
Гораздо меньше кода нужно написать, и намного проще читать!
Для группировки статических методов мы создаем утилитарные классы, в которых необходимо определить приватные конструкторы, чтобы предотвратить их инстанциацию. Также нам приходится помнить, в каком конкретном утилитарном классе находится статический метод. Это только дополнительные хлопоты. Я предлагаю добавить глобальные функции в Java и дополнительные «пространства имён» для их группировки. Взгляните на этот утилитарный класс:
Теперь посмотрите на эту глобальную функцию с пространством имён:
Моя точка зрения заключается в том, что поскольку мы уже используем классы как наборы функций, давайте сделаем это удобнее. В некоторых приложениях нам даже не понадобятся пространства имён, только глобальные функции, как в C и C++.
Чтобы получить доступ к приватному атрибуту или методу объекта извне, мы должны использовать API отражения. Это не особо сложно, но требует написания нескольких строк кода, которые не так просто прочитать и понять.
Я предлагаю разрешить любому объекту получать доступ к любым атрибутам и методам другого объекта.
Конечно, если они являются приватными, компилятор выдаст предупреждение. Во время компиляции вы просто игнорируете предупреждение и продолжаете. Если вам действительно важна инкапсуляция, обратите внимание на предупреждение и сделайте что-то другое. Но в большинстве случаев программисты его игнорируют, так как они всё равно с удовольствием используют Reflection API.
Было бы удобно позволить нам вызывать конструкторы и методы с неполным набором аргументов. Аргументы, которые мы не предоставляем, по умолчанию будут установлены в null. Также, когда метод должен вернуть что-то, но нет оператора return, Java должна возвращать null. Это почти точно так работает в PHP, Ruby и многих других языках. Я считаю, что это была бы удобная функция и для разработчиков на Java.
Нам не нужно определять так много методов, когда некоторые аргументы являются необязательными. Перегрузка методов очень громоздка и сложна для понимания. Вместо этого, у нас должен быть один метод с длинным списком аргументов. Некоторые из них будут предоставлены вызывающей стороной, а другие будут установлены в null. Метод будет решать, что делать, например:
Затем мы просто вызываем save(f) или save(f, "UTF-16"). Метод поймет, что мы имеем в виду. Мы также можем сделать это еще удобнее, как это сделано в Ruby, предоставляя аргументы метода по именам.
Также, когда нет ничего, что нужно вернуть, метод должен по умолчанию возвращать null. Запись return null просто является пустой строкой кода и не улучшает читаемость. Посмотрите:
Из этого кода очевидно, что если файл существует, метод загружает и возвращает его содержимое. Если же файла нет, он возвращает null, что будет хорошим индикатором для вызывающей стороны, что что-то не так и содержимое файла недоступно.
Я считаю, что это очевидно, что нам нужна эта функция: каждый приватный атрибут должен автоматически иметь сеттер и геттер. Не должно быть необходимости создавать их, Java предоставит их из коробки, также как и Kotlin и Ruby делают. В чем смысл иметь атрибут, если нет геттеров и сеттеров, чтобы его прочитать и изменить, верно?
С этой новой функцией нам больше не понадобится помощь Lombok или IntelliJ IDEA.
Может быть, мне стоит превратить свои идеи в официальные предложения для JCP. Что вы думаете?
Translated by ChatGPT gpt-3.5-turbo/42 on 2023-12-05 at 22:24
