Почему у Java нет автоматических свойств, таких как C #? [закрыто]

Ага, потому что его там нет. Как говорится, все функции начинаются нереализованными.

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

.net появился после Java, и одной из его целей было взаимодействие с COM. У COM были свойства, вероятно, как у VB, поэтому .net пришлось добавить их, чтобы сделать языки совместимыми. (К тому же, это была довольно красивая идея).

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

Автоматические свойства строятся на свойствах.

Свойства в C# - это особенность языка, в Java - это соглашение (методы, начинающиеся с get или set, часто считаются свойствами людьми, говорящими о коде, но для компилятора они ничем не отличаются от foo или bar).

.NET и связанные с ним языки во многом основывались на COM (иногда следуя примеру, иногда намеренно не делая в COM то, что по тем или иным причинам было непопулярно).

COM имеет концепцию свойств, которая в VB была подкреплена особенностями языка (в C++ она была подкреплена соглашениями).

Ранние версии VB, особенно в контекстах, где он использовался для обеспечения базового программного доступа к объектным моделям, предоставленным из других источников, стремились упростить объектные модели, представленные пользователям, чтобы сделать различие между полем и методом, который получает или устанавливает (возможно, с дополнительной работой, возможно, нет) несущественным (учтите, что хотя они отличаются некоторым важным способом извне в .NET, синтаксически доступ к свойству и публичному полю одинаков). Когда VB и COM (а до этого OLE) росли, они росли вместе.

Итак, в целом, хотя C# разделяет наследование C/C++ с Java, у него также есть наследование, которое Java не разделяет, что сделало свойства хорошей идеей для создателей C#, но не для создателей Java.

Edit: At first I said:

Лично я думаю, что автоматические свойства - это обходной путь к недостатку свойств, а не способ упростить ваш код. Свойства "выглядят" как публичные поля синтаксически, но не являются ими полностью (попробуйте использовать DataBinder.Eval для получения поля). Если бы свойство было полностью публичным и не имело дополнительной функциональности в getter или setter (как в случае с автоматическими свойствами), я бы предпочел иметь просто публичное поле (инкапсуляция здесь не аргумент, так как полное публичное раскрытие все равно обходит это), но различия между полями и свойствами работают против этого.

Я отказываюсь от этого утверждения. Если сделать поля точно такими же, как свойства, то поля простых структур Plain-Old-Data должны будут действовать как свойства, что приведет к снижению производительности. Концептуально, я бы хотел, чтобы они были более похожи друг на друга, но всякий раз, когда я думаю об этом (а я не раз переходил от раздражения к "ой, подождите", как здесь), оказывается, что лучше так, как есть.