Воспользуйтесь сгенерированными геттерами и сеттерами в Play! фреймворк - PullRequest
9 голосов
/ 27 сентября 2011

Играть!Framework генерирует геттеры и сеттеры для каждого открытого поля класса модели во время выполнения .

public class Product {

    public String name;
    public Integer price;
}

будет преобразовано в

public class Product {

    public String name;
    public Integer price;

    public String getName() {
        return name;
    }

    public void setName(String name) {
        this.name = name;
    }

    public Integer getPrice() {
        return price;
    }

    public void setPrice(Integer price) {
        this.price = price;
    }
}

В руководстве поясняетсядалее:

Тогда, когда вы захотите получить доступ к свойству, вы можете просто написать:

product.name = "My product";
product.price = 58;

, что переводится во время загрузки в:

product.setName("My product");
product.setPrice(58);

...и предупреждает:

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

Поскольку я не могу использовать эти методы получения и установки извне Play!Проект, я не вижу никакой выгоды в их создании.Какая выгода по сравнению с общедоступными полями, принимая во внимание рефакторинг (инкапсулирование поля и изменение вызывающих абонентов) всех современных IDE?

Ответы [ 3 ]

8 голосов
/ 27 сентября 2011

Другая причина - хотя вам не нужно указывать сеттеры и геттеры, вы все равно можете!

Итак, если у вас есть (по вашему примеру)

product.name = "my product"

Это хорошо, и делает ваш код быстрее и, на мой взгляд, легче для чтения.Однако для инкапсуляции есть веская причина для сеттеров и геттеров.Если вы хотите добавить некоторую логику при изменении имени вашего product.name, вы можете указать свой собственный установщик, но вам не нужно изменять приведенный выше код, поскольку он будет продолжать вызывать установщик за кулисами.

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

Мне кажется, это лучшее из обоих миров.

8 голосов
/ 27 сентября 2011

Краткий ответ: Бобы требуют их.

Дольше: спецификация Beans требует (среди прочего) метода получения / установки для каждого внутреннего поля. Я не уверен на 100%, но я предполагаю, что оба шаблона Hibernate и Groovy ожидают Java Beans (POJO Beans, а не Java EE!), Поэтому они будут запрашивать методы получения / установки. Игра просто экономит ваше время на этом, поэтому вам не нужно беспокоиться о коде котла (если вы не хотите по какой-то причине определить свой собственный метод получения / установки, что вы можете сделать).

0 голосов
/ 10 декабря 2014

Если у вас есть частный метод получения / установки, он не будет работать, так как невозможно создать открытый метод получения / установки с тем же именем.Так что это не удастся во время выполнения!

...