Почему Java Beans требует доступа?

Question

пожалуйста, не пытайтесь убить меня всеми разговорами "только право доступа" ... Я пришел с миром:)

Я просто хотел бы спросить, какова основная причина того, что JavaБины ДОЛЖНЫ использовать средства доступа даже в ситуациях, когда требуется только простой доступ к атрибутам.Я знаю, что в определенных ситуациях средства доступа хороши.Но, как говорится в моей любимой статье, «не используйте аксессоры, если вы не уверены на 100%, что вам нужен больше, чем простой доступ к атрибутам, это пустая трата времени процессора и программиста».

Опять же, пожалуйста, не атакуйте меняза неиспользование аксессоров все время.Я только спрашиваю, по какой причине он ДОЛЖЕН использоваться для того, чтобы использовать и создавать надлежащий Java Bean.Почему люди в Oracle говорят, что давайте делать это так ... Спасибо.

Answer 1

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

На самом деле в википедии есть хорошее объяснение: http://en.wikipedia.org/wiki/JavaBean

Answer 2

Основная причина использования аксессоров заключается в том, чтобы иметь полный контроль над своими модификациями в одном месте.

• Например, допустим, у вас есть коллекция, которая возвращается по ссылке из класса, в этом случае очень трудно отследить, добавлено ли что-то в коллекцию или нет. Хорошая практика - всегда возвращать копию коллекции в методе получения
• Другое использование состоит в том, чтобы иметь, например, только свойства только для чтения, и я не говорю о конечных переменных, а только для чтения для внешнего мира и строго контролируется внутренним миром (это очень полезно, когда операции над объектами, которые отображаются на БД просмотров)
• для модульного тестирования его можно использовать при макете (проверке вызова установщика)
• вы всегда можете создать прокси-объект, который позволяет нам предоставлять некоторую дополнительную логику, такую ​​как некоторая проверка или исправления данных
• при создании сущностей JPA я предпочитаю внедрение полей для инициализации JPA-провайдера и инициализации свойств для клиентской логики - но это мое субъективное мнение
• во время отладки иногда очень полезно поставить точку останова на сеттер, чтобы увидеть, как волшебным образом изменяется значение некоторого свойства
• когда внутренняя структура класса изменяется внутри контракта (методы доступа) остаются прежними
• отложенная инициализация некоторых свойств

Я мог бы найти еще много причин ...:)

ИМХО, используя аксессоры и мутаторы, дает возможность сделать наш код более расширяемым и намного более гибким

Answer 3

Хотя это является обязательным требованием для оригинальных Java-бинов, согласно соглашению, стоит отметить, что многие библиотеки, поддерживающие «бины», также рассматривают открытые поля как допустимые методы доступа;и обычно также позволяют использовать аннотации для указания непубличных методов и полей.Это включает в себя библиотеки, такие как JAXB (для привязки данных XML-к-POJO) и Джексона (JSON-к-POJO).

Таким образом, в некоторых отношениях оригинальная «спецификация» Java-бина (соглашение, описанное в JDK JDK)не все это уже актуально.

Я предполагаю, что авторы оригинальных конвенций просто считали, что прямой доступ к полям не является хорошей практикой.Лично я думаю, что есть случаи, когда простые неизменяемые классоподобные классные классы хороши, и довольно глупо писать код обезьяны для геттеров (или сеттеров для изменяемых);но есть тонкая грань между «структурами Java» (только данные, без логики или, самое большее, очень мало) и «реальными» объектами (состояние и поведение).

Answer 4

Фактически, Java-бин является -бином , если он следует соглашениям:

• Класс должен иметь открытый конструктор по умолчанию без аргументов.
• Свойства класса должны быть доступны с помощью get, set, is. Средства доступа, если вы предпочитаете.
• Класс должен быть сериализуемым.

источник

Так что это просто вопрос соглашений ...

Answer 5

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

Если вам нужно изменить внутреннее хранилище bean-компонента, вы можете сделать это и сохранить те же самые getter / settes.

Например: если у вас есть класс для хранения IP-адреса, вы можете не хранить его как длинное значение вместо строки (для эффективности). Вы можете сделать это, внеся изменения только в один класс.

Также взгляните на GRASP , особенно Information Expert

Answer 6

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