Бобы Java: Что я пропускаю?

мне нравятся мои объекты сделать как можно больше инициализации в конструкторе и иметь минимальное количество мутаторов.

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

, Например, предположите, что у Вас есть набор бобов Человека, и каждый боб имеет свойства, такие как имя, возраст, высота, и т.д.

можно отсортировать этот набор бобов по имени (например), использование следующего кода:

Collection<Person> myCollection = // initialise and populate the collection
Comparator nameCompare = new BeanComparator("name");
Collections.sort(myCollection, nameCompare);

класс BeanComparator знает, как извлечь свойство "имени" из каждого объекта, потому что Бобовое соглашение Java сопровождается, т.е. Вы сэкономлены "издержки" реализации интерфейса, такого как:

interface Nameable {
    public String getName();
    public void setName(String name);
}

Другой пример от Spring MVC является бобом, который хранит параметры URL запроса. Это может быть определено в веб-контроллере (известный как 'Действие' в Struts) как это:

public ModelAndView searchUsers(UserSearchCriteria criteria) {
    // implementation omitted
}

, поскольку UserSearchCriteria, как ожидают, будет JavaBean, если URL запроса будет содержать параметр такой как maxItems=6, платформа Spring 'знает', что это должно назвать метод с подписью

void setMaxItems(int maxItems);

В сущности, JavaBeans является просто простым соглашением, которое позволяет свойствам класса быть обнаруженными динамично во времени выполнения (обычно инструментом или платформой), когда это неудобно/невозможно для знания априорно свойств, которые могут быть обеспечены.

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

Для получения лучшего из "обоих миров" я думаю, что хороший вариант состоит в том, чтобы использовать шаблон Разработчика , немного изменяя Разработчика для исполнения стандарта JavaBeans. Так, при необходимости в функциональности платформы, которая требует, чтобы класс выполнил стандарт JavaBeans, можно использовать Разработчика вместо этого фактический класс.

Когда Вы услышите, что слово "боб" ожидает смотреть на какой-то "контейнер". Идея JavaBean любого вида состоит в том, чтобы предоставить универсальное интерфейсное соглашение для компонентов, которые могут добавляться и управляться во время выполнения. Плоскость JavaBeans является просто самым простым примером этого: это представляет все интерфейсные возможности и является сериализуемым, что означает, что можно создать экземпляры боба, изменить их, сохранить их и перезагрузить их.

Long и давно, я пишу редактору Java, который содержал простую "базу данных", представляющую текстовые строки, и имел, "включают архитектуру", которая использовала бобы. Вы могли добавить поведение к редактору путем перетаскивания боба из бобового мусорного ведра устройства хранения данных и отбрасывания его на редакторе; как только Вы сделали, поведение (скажите, Cntl-T для перемещения символов в курсоре) было автоволшебно доступно в редакторе. Бобы имели известный интерфейс---, они знали, как попросить у контейнера его структуры данных и doSomething (), метод---и контейнер знал, чтобы динамично загрузить файл класса, инстанцировать объекта и установить его доступ к базе данных.

Между прочим, это не действительно обязательно верно, что средства доступа нарушают инкапсуляцию; это однако верно, что просто, потому что у Вас есть участник, Вы не делаете , потребность для обеспечения добирается и методы установки для него. Спецификация JavaBean немного неясна на этом; точка должна предоставить методам get и методам set для тех вещей, которые должны быть в объектах "контрактом".

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

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

Примеры этих инструментов:

В спящем режиме
JMX