У С# есть автоматические свойства, которые значительно упрощают ваш код:
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 не реализовала что-то вроде этого?
Не так просто добавлять новые функции к существующему языку программирования, особенно если вы заботитесь о обратной совместимости. Sun всегда была очень осторожна с добавлением новых функций в Java, потому что они хотели быть абсолютно уверены, что любая новая функция языка не сломает миллионы программ Java, которые были написаны на протяжении многих лет.
Итак, это не просто вопрос добавления этого языка; вы должны очень тщательно подумать и попробовать, чтобы узнать, нет ли каких-либо тонких проблем с обратной совместимостью с любой новой функцией, которую вы хотите добавить.
Были предложения по добавлению поддержки свойств в той или иной форме в Java, но похоже, что для Java 7 (следующая версия подходит) это не функция, которая рассматривается.
Возможно, вам стоит взглянуть на Project Lombok, который является своего рода расширением Java, используя аннотации, чтобы сделать возможным напишите более сжатый код (он может, например, автоматически генерировать геттеры и сеттеры для полей).
Да, потому что у него его нет. Как говорится, все функции начинаются без выполнения.
Автоматические свойства основаны на свойствах.
Свойства в С# - это языковая функция, в Java это соглашение (методы, начинающиеся с get или set, часто считаются свойствами людей, говорящих о коде, но для компилятора он не отличается от foo или bar).
.NET и связанные с ним языки, которые во многом основаны на COM (иногда в следующем порядке, иногда сознательно не что-то делает в COM, который по какой-то причине непопулярен).
COM имеет представление о свойствах, которые в VB поддерживались языковыми функциями (в С++ он поддерживался соглашениями).
Ранние версии VB, особенно в тех контекстах, где он использовался для обеспечения базового программного доступа к объектным моделям, предоставленным из других источников, направленных на упрощение моделей объектов, представленных пользователям, чтобы провести различие между полем и методом, который получает или устанавливает (возможно, с дополнительной работой, возможно, неважно) неважно (учтите, что, хотя они отличаются каким-то важным способом извне в .NET, синтаксически доступ к свойству и публичному полю одинаковый). Когда VB и COM (и до этого OLE) выросли, они выросли вместе.
Таким образом, в то время как С# разделяет наследование C/С++ с Java, он также имеет наследование, которое Java не разделяет, что заставляет свойства казаться хорошей идеей для создателей С#, но не для Java.
Изменить: Сначала я сказал:
Лично я считаю, что автоматические свойства действительно являются обходным путем к недостатку свойств, а не к упрощению кода. Свойства "выглядят" как публичные поля синтаксически, но не полностью (попробуйте использовать DataBinder.Eval для извлечения поля). Если свойство было полностью публичным и не имело дополнительных функций в getter или setter (что имеет место с автоматическими свойствами), я бы предпочел бы просто публичное поле (инкапсуляция не является аргументом здесь, поскольку полностью раскрывает его публично, это все равно), но различия между полями и свойствами работают против этого.
Я отменяю это утверждение. Создание полей точно так же, как и свойств, потребует, чтобы поля простых структур Plain-Old-Data действовали как свойства, что было бы неплохим. Понятно, что я бы хотел, чтобы они были больше похожи друг на друга, но всякий раз, когда я думаю об этом (и я ушел от того, что меня раздражало, что "о, подождите", как здесь, не раз), это лучше, чем есть.
По той же причине у С# 2.0 или ниже этого нет. Это больше или синтаксический сахар, а язык. Существует множество функций, подобных этому, которые могут быть добавлены на любой язык, но никто не знает, почему они не являются языком.
.net появился после Java, и одной из его целей было взаимодействие с COM. У COM были свойства, возможно, a la VB, поэтому .net все, но пришлось добавить их, чтобы сделать языки совместимыми. (Это, и они были довольно симпатичной идеей.)
У Java не было такой необходимости, и ее создатели, вероятно, не хотели загрязнять значение "=" или делать вызовы функций похожими на переменные-члены. (Они - или, по крайней мере, были в какой-то момент - велики, чтобы поддерживать язык как можно более чистым). Их подход был вместо Java bean спецификаций, в котором указано соглашение об именах для геттеров и сеттеров. IDE, которые знают спецификацию, могут более или менее вымывать представление геттера и сеттера как единственное "свойство" для целей дизайна.