Отсутствие синтаксиса свойства в Java

В течение приблизительно 10 лет, солнце сопротивлялось любым существенным изменениям на язык настолько трудно, как они могли. В тот же период C# был канавкой захватывающая разработка, добавив хост новых замечательных функций с каждым выпуском.

Я думаю поезд, оставленный на свойствах в Java давным-давно, они были бы хороши, но у нас есть спецификация боба Java. Добавление свойств теперь просто сделало бы язык еще более сбивающим с толку. В то время как javabean спецификация, которая IMO нигде не рядом как хороший, он должен будет сделать. И в более великой схеме вещей я думаю, что свойства не действительно настолько релевантны. Чрезмерное увеличение размера в коде Java вызывается другими вещами, чем методы считывания и методы set.

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

Синтаксис свойства в C# является не чем иным как синтаксическим сахаром. Вам не нужен он, это только там как удобство. Людям Java не нравится синтаксический сахар. Это, кажется, причина достаточно ее отсутствия.

Возможные аргументы на основе не чего иного как моего неинформированного мнения

• синтаксис свойства в C# является ужасным взломом, в котором он смешивает шаблон реализации с синтаксисом языка
• Это не действительно необходимо, поскольку это довольно тривиально.
• Это было бы adversly влиять на любого заплаченного на основе строк кода.

Я на самом деле хотел бы там быть своего рода синтаксическим сахаром для свойств, поскольку целый синтаксис имеет тенденцию загромождать код, это концептуально чрезвычайно просто. Ruby для каждый, кажется, делает это без большого количества суеты.

На ноте стороны я на самом деле попытался записать некоторые системы среднего размера (несколько дюжин классов) без доступа свойства, только из-за сокращения помехи и размера кодовой базы. Кроме небезопасных вопросов проектирования (от которого я был готов уклониться в этом случае) это почти невозможно как каждая платформа, каждая библиотека, каждый все в Java автообнаруживает, что свойства добираются и методы установки. Они с нами до самого конца времени, вида подобных небольших синтаксических учебных колес.

Я сказал бы, что это отражает замедление изменения на языке. Как предыдущий комментатор упомянул с большинством IDE теперь, это действительно не является настолько большим из соглашения. Но нет никакой JVM определенных причин его, чтобы не быть там.

Могло бы быть полезным для добавления к Java, но это находится, вероятно, не настолько высоко в списке как закрытия.

Лично, я нахожу, что достойный IDE делает это спорным вопросом. IntelliJ может генерировать все методы считывания/методы set для меня; все, что я должен сделать, встраивают поведение, которое Вы сделали в методы. Я не нахожу, что это недопустимое.

Я признаю, что я не хорошо осведомлен о C#, поэтому возможно, те, кто, отвергнет меня. Это - просто мое мнение.

Если бы я должен был предположить, то я сказал бы, что это меньше имеет отношение к философскому возражению на синтаксический сахар (они добавили автоупаковку, улучшенную для циклов, статического импорта, и т.д. - весь сахар), чем с проблемой с назад совместимостью. До сих пор, по крайней мере, люди Java попытались очень трудно разработать новые функции языка таким способом, которым исходным уровнем назад совместимость сохраняется (т.е. код, написанный для 1,4, все еще скомпилирует, и функция, без модификации в 5 или 6 или вне).

Предположим, что они представляют синтаксис свойств. Что, затем делает следующее среднее:

myObj.attr = 5;

Это зависело бы от того, говорите ли Вы о коде, записанном прежде или после добавления функции свойств, и возможно на определении самого класса.

Я не говорю, что эти вопросы не могли быть решены, но я скептически настроен, они могли быть разрешены способом, который привел к чистому, однозначному синтаксису при сохранении исходной совместимости с предыдущими версиями.

Люди Python могут сходить с рук взлом старого кода, но это не путь Java...

Это - та же причина, что они не изменяют ничто больше в Java - назад-совместимость.

- Это, потому что это не считало достаточно важным по сравнению с другими возможными улучшениями?

Это - мое предположение.

- Там являются техническими (например, связанными с JVM), ограничения?

Нет

- Действительно ли это - вопрос политики? (например, "Свойства I have been coding in Java for 50 years now and I say: we do not need no steenkin '!")

Скорее всего.

- Действительно ли это - случай bikeshedding?

Мм?

Одна из главных целей Java состояла в том, чтобы сохранить язык простым.

От: Википедия

Java подавляет несколько функций [...] классов для упрощения языка и предотвратить возможные ошибки и дизайн антишаблона.

Вот несколько небольших битов логики, которые, для меня, приводят к не симпатии свойств на языке:

Некоторые структуры программирования привыкают, потому что они там, даже если они поддерживают плохие практики программирования.

Методы set подразумевают изменяемые объекты. Что-то для использования редко.

Хороший дизайн OO Вы спрашиваете объект сделать некоторую бизнес-логику. Свойства подразумевают, что Вы просите у этого данные и управляете данными сами.

Хотя Вы переопределение CAN методы в методах set и методах считывания, немногие когда-либо делают; также заключительная общедоступная переменная является ТОЧНО тем же как методом считывания. Таким образом, если у Вас нет изменяемых объектов, это - своего рода спорный вопрос.

Если Вашей переменной связали бизнес-логику с ним, логика должна ОБЫЧНО быть в классе с переменной. ЕСЛИ это не делает, почему в мире является это переменной??? это должно быть "Данными" и быть в структуре данных, таким образом, этим может управлять общий код.

Я полагаю, что Jon Skeet указал, что C# имеет новый метод для обработки этого вида данных, Данные, которые должны быть введенным временем компиляции, но не должны действительно быть переменными, но являющийся, что мой мир имеет очень мало взаимодействия с миром C#, я просто возьму его слово, что это довольно прохладно.

Кроме того, я полностью признаю, что в зависимости от Вашего стиля и кода Вы взаимодействуете с, у Вас просто должна быть установить/получить ситуация время от времени. Я все еще насчитываю один метод set/метод считывания каждый класс или два, но недостаточно заставить меня чувствовать, что новая структура программирования выравнивается по ширине.

И обратите внимание, что у меня есть совсем другие требования для работы и для домашнего программирования. Для работы, где мой код должен взаимодействовать с кодом 20 других людей, я верю чем более структурированный и явный, тем лучше. Дома Groovy/Ruby прекрасен, и свойства были бы большими и т.д.