Java Beans: что мне не хватает?
https://stackoverflow.com/questions/315142
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianВопрос
Мне интересно, что-то упущено в Java Beans. Мне нравится, когда мои объекты выполняют как можно больше инициализации в конструкторе и имеют минимальное количество мутаторов. Бобы, кажется, идут прямо против этого и в целом чувствуют себя неуклюже. Какие возможности я упускаю, если не строю свои объекты как Бины?
Решение
Похоже, вы на правильном пути. Не вы упускаете из виду смысл Java Beans, а другие программисты злоупотребляют ими.
Спецификация Java Beans была разработана для использования с визуальными инструментами. Идея заключалась в том, что разработчик приложения сможет интерактивно настраивать экземпляр объекта, а затем сериализовывать (или генерировать код) настроенный компонент, чтобы его можно было восстановить во время выполнения; предполагалось, что он не будет видоизменяться во время выполнения.
К сожалению, многие разработчики не понимают, что это > средства доступа нарушают инкапсуляцию . Они используют структуры вместо объектов. Они не видят ничего плохого в других классах, даже в других пакетах, имеющих зависимости от членов данных класса.
Конечно, вам, как правило, нужно настраивать экземпляры ваших объектов. Просто это должно быть сделано через какую-то особенность конфигурации. Это может быть контейнер для инъекций зависимостей, а именно «BeanBox». стиль визуального инструмента, или просто чтение JSON, XML или файлов свойств, которые вы написали от руки. Ключ в том, что во время выполнения эти объекты эффективно неизменяемы; клиенты просто вызывают свои операции, они не имеют доступа к своим свойствам.
Другие советы
Мне нравится, что мои объекты делают столько же инициализация в конструкторе как возможно и иметь минимальное количество мутаторов.
Любить неизменные объекты - мудрый выбор. Однако преимущество bean-компонентов заключается в том, что фреймворки / инструменты / библиотеки могут определять свойства класса во время выполнения, не требуя реализации конкретного интерфейса.
Например, предположим, что у вас есть коллекция bean-компонентов Person, и у каждого bean-компонента есть такие свойства, как имя, возраст, рост и т. д.
Вы можете отсортировать эту коллекцию бинов по имени (например), используя следующий код:
Collection<Person> myCollection = // initialise and populate the collection
Comparator nameCompare = new BeanComparator("name");
Collections.sort(myCollection, nameCompare);
Я разделяю идею, что минимизация изменчивости - это хорошо. Как уже указывалось, преимущество JavaBeans заключается в том, что они легко обрабатываются фреймворками. Чтобы получить лучшее из "обоих миров", я думаю, что хорошим вариантом является использование Шаблон Builder , слегка изменяя Builder для соответствия стандарту JavaBeans. Поэтому, если вам нужна функциональность платформы, которая требует, чтобы ваш класс соответствовал стандарту JavaBeans, вы можете использовать Builder вместо фактического класса.
Когда вы слышите слово «боб» ожидайте, что будете смотреть на «контейнер» какой-то Идея JavaBean любого рода состоит в том, чтобы обеспечить единообразное соглашение об интерфейсе для компонентов, которые можно добавлять и управлять ими во время выполнения. Простые JavaBeans - это просто простейший пример этого: он представляет все возможности интерфейса и является Сериализуемым, что означает, что вы можете создавать экземпляры компонента, изменять их, сохранять и перезагружать их.
Давным-давно я пишу Java-редактор, который содержал простую " базу данных " представлял текстовые строки и имел «плагин в архитектуре» которые использовали бобы. Вы можете добавить поведение в редактор, перетаскивая bean-компонент из хранилища bean-компонентов и помещая его в редактор; После этого поведение (скажем, Cntl-T для транспонирования символов в курсоре) автоматически стало доступно в редакторе. Бины имели известный интерфейс - они знали, как запрашивать у контейнера структуру данных, и метод doSomething () - и контейнер знал, что нужно динамически загружать файл класса, создавать экземпляр объекта и устанавливать его доступ к база данных.
Кстати, это не обязательно так, что методы доступа нарушают инкапсуляцию; однако верно то, что только потому, что у вас есть член, вам не нужно предоставлять методы get и set для него. Спецификация JavaBean немного неясна по этому поводу; Суть в том, чтобы предоставить геттеры и сеттеры для тех вещей, которые должны быть в объектах «контракт».
После того, как интроспекция и рефлексия были добавлены к языку и по-настоящему понятны, необходимость в этих соглашениях несколько уменьшилась; в ранней Java вам нужно было договориться о поиске методов.
