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

Question

C# имеет автоматические свойства, которые значительно упрощают код:

public string Name { get; set; } 
public string MiddleName { get; set; } 
public string LastName { get; set; } 

В то время как Java имеет писать столько кода:

private String name; 
private String middleName; 
private String LastName; 

public String Name(){ 
    return this.name; 
} 

etc.. 

Есть ли конкретная причина, Java не реализован что-то вроде этого?

Answer 1

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

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

Были предложения по добавлению поддержки свойств в той или иной форме на Java, но похоже, что для Java 7 (следующая версия подходит) это не функция, которая рассматривается.

Возможно, вы захотите взглянуть на Project Lombok, что является расширением Java, используя аннотации, чтобы дать возможность писать более сжатый код (он может, например, автоматически генерировать геттеры и сеттеры для полей) ,

Answer 2

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

Answer 3

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

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

Answer 4

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

Answer 5

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

Свойства на 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: Сначала я сказал:

---

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

---

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