Что такое хороший вариант использования Java Beans?

Question

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

Может ли кто-нибудь указать мне хороший прецедент для использования такого дизайна? Я не могу понять это. Есть одно использование, о котором я могу думать: «Когда вам нужно создать экземпляр класса, так что его члены данных будут определены позже в коде».

EDIT: Ребята, я не начинаю обсуждение. Не хочу обсуждать преимущества/недостатки. Я не ищу текущие библиотеки, такие как spring и т. Д., Что делает обязательным использование Beans. Я ищу пример, чтобы понять технические преимущества, которые принесет Java-бобы. «Только один пример, где дизайн Java Beans поможет»

Answer 1

Несколько библиотек и спецификаций (например, JPA, JavaEL) используют спецификацию Java Beans и полагаются именно на это поведение.

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

Кроме того, использование геттеров и сеттеров позволяет другим фреймворкам обертывать эти методы и предоставлять дополнительные функции, такие как ведение журнала изменений и т. Д. Во многих случаях это делается путем внутреннего создания подкласса и переопределения геттеров и сеттеров. Пользователь не заметил бы этого, поскольку это «ткачество» или «проксирование» часто выполняется во время выполнения. Например, Hibernate использует это для обеспечения ленивой функциональности загрузки, когда вы вызываете getter для доступа к соответствующей коллекции или сущности.

Update:

По желанию пример для "виртуальных" свойствами:

Предположим, у вас есть Person боб, который имеет поля firstName и lastName. Вы можете добавить виртуальную собственность name только для чтения, предоставляя следующие поглотитель:

public String getName() { 
    return getFirstName() + " " + getLastName(); 
} 

Update 2:

Еще одно замечание о том, почему методы получения и установки необходимы: это в основном идет от того, как работает Java. Языки, которые непосредственно поддерживают свойства, такие как C#, позволят вам написать код, например person.firstName = "Joe";, и по-прежнему использовать сеттер, если он есть, или выбросить ошибку, если свойство доступно только для чтения. Поэтому, если вы добавите установщик для firstName, эти языки будут внутренне переводить firstName = "Joe" в setFirstName("Joe") без необходимости изменения разработчика - довольно элегантное решение. :)

Поскольку Java не поддерживает это, мы должны всегда предоставлять методы доступа (сеттеры/геттеры), даже если они не делают ничего особенного - на случай, если они могут необходимо изменить в будущем ,

Answer 2

JavaBeans, как вы описали выше, может использоваться как DAO (объекты доступа к данным) для извлечения и сохранения данных в базу данных SQL.Они полезны, когда все, что вы действительно заботитесь о том, что данные

Answer 3

геттеров & Сеттеров обеспечивает the basic object oriented concept - Encapsulation

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

Таким образом, вы должны

Keep instance variables protected (с access modifier, often private).

Сделать public accessor methods, и сила вызова код, чтобы использовать эти методы rather than directly accessing the instance variable.

Их код выявил ошибки в вашем коде.

смотрите в следующем примере,

public class MyClass{ 
public int size; 
public int weight; 
... 
} 
public class OthersClass { 
public static void main (String [] args) { 
MyClass myClass= new MyClass(); 
myClass.size = -5; // Legal but bad logic 
} 
} 

Answer 4

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

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

Кроме того, я думаю, вы воображаете класс с большим количеством, которое атрибут объявления будет трудно заполнить только добытчиками и сеттеров, но и отметить это указывает:

• Геттеры будет автоматизируют вид части.
• Сетчатчики позволят вам при необходимости добавить проверку или проверку ошибок.

Answer 5

Многие люди расскажут вам, что Java-бобы намного лучше, чем обычные объекты Java, которые действуют как «объекты передачи данных».

Но другие люди, например, этот парень здесь, в своей известной книге https://cleansourcecode.files.wordpress.com/2013/10/clean-code.pdf предполагают, что чаще всего, «бобы» и добытчики и сеттера действительно имеют не много дополнительных значения (вся глава 6 посвящена этот вопрос).

Итак, вы должны решить для себя (и, вероятно, с товарищами по команде), если ваша проблема лучше решена с помощью «Java Beans» или «простых объектов передачи данных».

Конечно, «бобы» заставляют вас использовать сеттеры, которые позволят вам впоследствии добавить подтверждение. С другой стороны: такое изменение изменяет семантику ваших методов; и может быть совершенно неправильно, что внезапно сеттер выполняет проверку и начинает бросать исключения.Потому что, если вы меняете договор своих методов; вы можете не захотеть делать это неявно под обложками.

Answer 6

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

Я не знаю, был ли этот подход к программированию успешным и был принят (я никогда не использовал его лично). Я знаю, что спецификация продолжала жить и применяться очень широко (ИМХО иногда также в контекстах, в которых это было не самое подходящее).

Я думаю, что наиболее полезным местом, в котором могут использоваться JavaBeans, является framework. Хорошим примером является Spring. Класс JavaBean очень подходит, когда экземпляр класса не несет ответственности за программиста, но делегируется контейнеру приложения (например, через отражение).