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

Question

C # имеет синтаксис для объявления и использования свойств. Например, можно объявить простое свойство, например так:

public int Size { get; set; }

Также можно добавить немного логики в свойство, например:

public string SizeHex
{
    get
    {
        return String.Format("{0:X}", Size);
    }
    set
    {
        Size = int.Parse(value, NumberStyles.HexNumber);
    }
}

Независимо от того, имеет ли он логику или нет, свойство используется так же, как поле:

int fileSize = myFile.Size;

Я не новичок ни в Java, ни в C # - я довольно часто использовал оба, и мне всегда не хватало синтаксиса свойств в Java. Я прочитал в этот вопрос , что «маловероятно, что поддержка свойств будет добавлена ​​в Java 7 или, возможно, когда-либо», но, честно говоря, я считаю, что это слишком много работы, чтобы копаться в дискуссиях, форумах, блогах, комментарии и JSR, чтобы выяснить, почему.

Итак, мой вопрос: кто-нибудь может подвести итог, почему Java вряд ли получит синтаксис свойства?

• Это потому, что он не считается достаточно важным по сравнению с другими возможными улучшениями?
• Существуют ли технические (например, связанные с JVM) ограничения?
• Это вопрос политики? (например, «Я программирую на Java уже 50 лет, и я говорю, что нам не нужны никакие свойства steenkin!» )
• Это случай велосипедных прогулок ?

Answer 1

Я думаю, что это просто общая философия Java в отношении вещей. Свойства несколько «магические», и философия Java заключается в том, чтобы основной язык был максимально простым и избегать магии, такой как чума. Это позволяет Java быть lingua franca , который может понять любой программист. Это также позволяет легко рассуждать о том, что делает произвольный изолированный фрагмент кода, и обеспечивает лучшую поддержку инструментов. Недостатком является то, что он делает язык более многословным и менее выразительным. Это не обязательно правильный или неправильный способ разработки языка, это просто компромисс.

Answer 2

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

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

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

Answer 3

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

Answer 4

Возможные аргументы, основанные только на моем неосведомленном мнении

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

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

Кстати, я на самом деле пытался написать некоторые системы среднего размера (несколько десятков классов) без доступа к свойствам, просто из-за уменьшения беспорядка и размера кодовой базы. Помимо небезопасных проблем проектирования (которые в этом случае я был готов выдумать) это практически невозможно, так как каждая инфраструктура, каждая библиотека, все в java автоматически обнаруживает свойства методами get и set. конец времени, вроде как маленькие синтаксические тренировочные колеса.

Answer 5

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

Answer 6

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

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

myObj.attr = 5;

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

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

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

Answer 7

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

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

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

Answer 8

Вам могут не понадобиться префиксы «get» и «set», чтобы они выглядели как свойства, вы можете сделать это так:

public class Person {
    private String firstName = "";
    private Integer age = 0;

    public String firstName() { return firstName; } // getter
    public void firstName(String val) { firstName = val; } // setter

    public Integer age() { return age; } // getter
    public void age(Integer val) { age = val; } //setter

    public static void main(String[] args) {
        Person p = new Person();

        //set
        p.firstName("Lemuel");
        p.age(40);

        //get
        System.out.println(String.format("I'm %s, %d yearsold",
            p.firstName(),
            p.age());
    }
}

Answer 9

Согласно 2-му изданию Core Java (забыли авторов, но это очень популярная книга), дизайнеры языка сочли плохой идеей скрыть вызов метода за синтаксисом доступа к полю и поэтому оставили его вне.

Answer 10

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

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

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

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

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

Если ваша переменная имеет бизнес-логику, связанную с ней, логика должна ОБЯЗАТЕЛЬНО находиться в классе с переменной. Если это не так, почему в мире это переменная ??? оно должно быть «Данные» и находиться в структуре данных, чтобы им можно было управлять с помощью общего кода.

---

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

Кроме того, я полностью согласен с тем, что в зависимости от вашего стиля и кода, с которым вы взаимодействуете, вы просто ДОЛЖНЫ время от времени иметь ситуацию установки / получения. Я по-прежнему усредняю ​​по одному сеттеру / геттеру каждый класс или два, но этого недостаточно, чтобы заставить меня почувствовать, что новая структура программирования оправдана.

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