(нет) Свойства в Java?

В Java существует стандартный шаблон для геттеров и сеттеров, который называется Свойства компонента< /а>. По сути, любой метод, начинающийся с get, не принимающий аргументов и возвращающий значение, является методом получения свойства для свойства, названного как остальная часть имени метода (с начальной буквой в нижнем регистре). Аналогично set создает сеттер метода void с одним аргументом.

// Getter for "awesomeString"
public String getAwesomeString() {
  return awesomeString;
}

// Setter for "awesomeString"
public void setAwesomeString( String awesomeString ) {
  this.awesomeString = awesomeString;
}

public boolean isAwesome();

public boolean hasAwesomeStuff();

Я удивлен, что никто не упомянул проект lombok

Да, в настоящее время в java нет свойств. Есть и другие недостающие функции.
Но, к счастью, у нас есть проект lombok, который пытается исправить ситуацию. Он также становится все популярнее с каждым днем.

Итак, если вы используете ломбок:

@Getter @Setter int awesomeInteger = 5;

Этот код также будет генерировать getAwesomeInteger и setAwesomeInteger. Так что это очень похоже на автоматически реализуемые свойства C#.

Дополнительную информацию о геттерах и сеттерах ломбока можно получить здесь.
Обязательно посетите другие функции. Мои любимые:

• val
• Конструктор NoArgs, Конструктор RequiredArgs, Конструктор AllArgs
• Журналы!

Lombok хорошо интегрирован с IDE, поэтому он будет показывать сгенерированные методы, как если бы они существовали (предложения, содержимое классов, переход к объявлению и рефакторингу).
Единственная проблема с lombok заключается в том, что другие программисты могут не знать об этом. . Вы всегда можете delombok код, но это скорее обходной путь, чем решение.

«Поддержка свойств Java» была предложена для Java 7, но не вошла в язык.

См. http://tech.puredanger.com/java7#property для получения дополнительных ссылок и информации, если интересно.

Соглашение bean-компонентов состоит в том, чтобы писать такой код:

private int foo;
public int getFoo() {
    return foo;
}
public void setFoo(int newFoo) {
    foo = newFoo;
}

В некоторых других языках JVM, например, в Groovy, вы получаете переопределяемые свойства, аналогичные C#, например,

int foo

доступ к которому осуществляется с помощью простого .foo и использует реализации по умолчанию getFoo и setFoo, которые вы можете переопределить по мере необходимости.

public class Animal {

    @Getter @Setter private String name;
    @Getter @Setter private String gender;
    @Getter @Setter private String species;
}

Это что-то вроде свойств C#. Это http://projectlombok.org/.

Вам могут не понадобиться префиксы «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());
    }
}

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

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

Конечно, Eclipse может модифицировать только тот код, о котором ему известно — любые внешние зависимости, которые у вас есть, могут быть нарушены таким рефакторингом.

Мой опыт работы с Java тоже не так высок, поэтому любой может меня поправить. Но AFAIK, общее соглашение состоит в том, чтобы написать два метода следующим образом:

public string getMyString() {
    // return it here
}

public void setMyString(string myString) {
    // set it here
}

Из книги Джеффри Рихтера CLR через C#: (я думаю, что это может быть причиной того, что свойства до сих пор не добавлены в JAVA)

• Метод свойства может вызвать исключение; доступ к полю никогда не вызывает исключения.
• Свойство нельзя передать методу как параметр out или ref; поле может.
• Выполнение метода свойства может занять много времени; доступ к полю всегда завершается немедленно. Распространенной причиной использования свойств является выполнение синхронизации потоков, которая может остановить поток навсегда, поэтому свойство не следует использовать, если требуется синхронизация потоков. В этой ситуации метод предпочтительнее. Кроме того, если к вашему классу можно получить доступ удаленно (например, ваш класс является производным от System.MarshalByRefObject), вызов метода свойства будет очень медленным, и поэтому метод предпочтительнее свойства. На мой взгляд, классы, производные от MarshalByRefObject, никогда не должны использовать свойства.
• Если метод свойства вызывается несколько раз подряд, он может каждый раз возвращать другое значение; поле каждый раз возвращает одно и то же значение. Класс System.DateTime имеет свойство Now только для чтения, которое возвращает текущую дату и время. Каждый раз, когда вы запрашиваете это свойство, оно возвращает другое значение. Это ошибка, и Microsoft хочет исправить класс, сделав Now методом, а не свойством. Свойство TickCount объекта Environment — еще один пример этой ошибки.
• Метод свойств может вызвать наблюдаемые побочные эффекты; доступ к полю никогда не делает. Другими словами, пользователь типа должен иметь возможность устанавливать различные свойства, определенные типом, в любом порядке, который он выбирает, не замечая никакого другого поведения в типе.
• Метод свойства может потребовать дополнительной памяти или вернуть ссылку на что-то, что на самом деле не является частью состояния объекта, поэтому изменение возвращаемого объекта не влияет на исходный объект; запрос поля всегда возвращает ссылку на объект, который гарантированно является частью исходного состояния объекта. Работа со свойством, возвращающим копию, может сильно запутать разработчиков, и эта характеристика часто не документируется.

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

Я просто выпускаю аннотации Java 5/6 и процессор аннотаций, чтобы помочь этому.

Ознакомьтесь с http://code.google.com/p/javadude/wiki/Annotations< /а>

@Bean(properties = {
    @Property(name="name", bound=true),
    @Property(name="age,type=int.class)
})
public class Person extends PersonGen {
}

В java нет ключевого слова свойства (как вы могли бы найти его в С#), ближайший способ получить 1 слово геттер/сеттер - это сделать как в С++:

public class MyClass
{
    private int aMyAttribute;
    public MyClass()
    {
        this.aMyAttribute = 0;
    }
    public void mMyAttribute(int pMyAttributeParameter)
    {
        this.aMyAttribute = pMyAttributeParameter;
    }
    public int mMyAttribute()
    {
        return this.aMyAttribute;
    }
}
//usage :
int vIndex = 1;
MyClass vClass = new MyClass();
vClass.mMyAttribute(vIndex);
vIndex = 0;
vIndex = vClass.mMyAttribute();
// vIndex == 1

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

Вы также можете сделать это с помощью NetBeans.

Чтобы создать методы доступа для вашего класса, откройте файл класса, затем щелкните правой кнопкой мыши в любом месте редактора исходного кода и выберите команду меню Refactor, Encapsulate Fields. Откроется диалоговое окно. Нажмите «Выбрать все», затем нажмите «Рефакторинг». Вуаля,

Удачи,

Для меня проблема состоит из двух частей:

1. Все эти дополнительные методы {get*/set*} загромождают код класса.
   
2. НЕ иметь возможности обращаться с ними как со свойствами:

    public class Test {
      private String _testField;

      public String testProperty {
       get {
        return _testField;
       }
       set {
        _testField = value;
       }
      }
    }

    public class TestUser {
      private Test test;

      public TestUser() {
        test = new Test();

        test.testProperty = "Just something to store";
        System.out.printLn(test.testProperty);
      }
    }

Это своего рода простое задание, к которому я хотел бы вернуться. НЕ нужно использовать синтаксис вызова метода. Может ли кто-нибудь дать некоторые ответы относительно того, что случилось с Java?

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

Мое текущее решение состоит в том, чтобы использовать «общедоступные» члены, когда защита не требуется:

public class IntReturn {
    public int val;
}

public class StringReturn {
    public String val;
}

Они будут использоваться для возврата значения, скажем, из лямбды:

StringReturn sRtn = new StringReturn()

if(add(2, 3, sRtn)){
    System.out.println("Value greater than zero");
}

public boolean add(final int a, final int b, final StringReturn sRtn){
    int rtn = a + b;
    sRtn.val = "" + rtn;
    return rtn > 0; // Just something to use the return for.
}

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

Если ваша информация передается как «неизменяемая», то решением может стать новая запись Java. Однако он по-прежнему использует методологию установки/получения, только без префиксов установки/получения.