Мне нравится, что мои объекты делают столько же
инициализация в конструкторе как
возможно и иметь минимальное количество
мутаторов.
Любить неизменные объекты - мудрый выбор. Однако преимущество bean-компонентов заключается в том, что фреймворки / инструменты / библиотеки могут определять свойства класса во время выполнения, не требуя реализации конкретного интерфейса.
Например, предположим, что у вас есть коллекция бинов Person, и у каждого бина есть такие свойства, как имя, возраст, рост и т. Д.
Вы можете отсортировать эту коллекцию бобов по имени (например), используя следующий код:
Collection<Person> myCollection = // initialise and populate the collection
Comparator nameCompare = new BeanComparator("name");
Collections.sort(myCollection, nameCompare);
Класс BeanComparator знает, как извлечь свойство "name" из каждого объекта, поскольку соблюдается соглашение Java Beans, т.е. вы избавлены от "накладных расходов" на реализацию интерфейса, такого как:
interface Nameable {
public String getName();
public void setName(String name);
}
Другим примером Spring MVC является bean-компонент, хранящий параметры URL-адреса запроса. Это можно определить в веб-контроллере (известном как «Действие» в Struts) следующим образом:
public ModelAndView searchUsers(UserSearchCriteria criteria) {
// implementation omitted
}
Поскольку ожидается, что UserSearchCriteria будет JavaBean, если URL-адрес запроса содержит такой параметр, как maxItems=6, среда Spring «знает», что должна вызвать метод с подписью
void setMaxItems(int maxItems);
По сути, JavaBeans - это просто простое соглашение, которое позволяет динамически обнаруживать свойства класса во время выполнения (обычно с помощью инструмента или инфраструктуры), когда априори неудобно / невозможно узнать свойства, которые могут быть предоставлены.